Keresés

Részletes keresés

annyi baj legyen Creative Commons License 2019.07.30 0 0 534

" egy meglévő rendszer adottságait, korlátait, amelynek a megváltoztatása nem ripsz-ropsz ügy"

Ez egy kb. tíz éves mantra, és azóta egy kapavágás sem történt. Pedig tíz év alatt nulláról meg lehetett volna írni mindent.

Előzmény: alnibell (531)
Pinus Nigra Creative Commons License 2019.07.30 0 0 533

Nincsen új szempont szerinti akadékoskodás, olyan szempontok vannak, amiket nem vettél figyelembe :D
Hangember.

Előzmény: alnibell (531)
Pinus Nigra Creative Commons License 2019.07.30 0 1 532

Ide a dinnyehéjat, alnibell ismét megfutamodott, amikor konkrét szakmai munkára lett volna szükség, marad a körmondatainál.
Hát, ez nem meglepő :)

Előzmény: alnibell (530)
alnibell Creative Commons License 2019.07.30 0 0 531

Már megbocsáss, de ez csak egy új szempont szerinti akadékoskodás.

 

Még a mostani gyakori útvonalváltozás számossága se éri el azt a küszöbértéket, amely egyrészt ne tenné lehetővé a változások könnyű átvezetését manuálisan, másrészt ha valami ráért kilenc évig, annak az esetleges néhány napos egyedi változási késedelme nem okozhat gondot.

 

És tessék már végre figyelembe venni egy meglévő rendszer adottságait, korlátait, amelynek a megváltoztatása nem ripsz-ropsz ügy, továbbá más mellet még azt, hogy teljesen fölösleges nagyágyút megalkotni egy hetente, havonta egy-egy alkalommal bekövetkező változás teljes biztonsággal történő átvezetéséhez. Nonszensz követelmény akkor, amikor a meglévő nyilvántartás részletek még egymással sem kompatibilisek, de mégis ragaszkodnak hozzájuk.

Azoknál csak jobbat lehetne alkotni, egységesen.

Előzmény: turablog (528)
alnibell Creative Commons License 2019.07.30 0 0 530

A tévedés, a hónapokon át tartó hibás feltételezés belátása helyett elkövetett aljasságot már tényleg nem lehet felülmúlni.

Tökéletesen igazolta, hogy a korábbi, az illetőre vonatkoztatott jellemzésem helytálló.

 

Az alább linkelt anyagban minden szükséges információ benne van. Így az is, hogy milyen az adattábla, meg az is, hogy nagyjából milyen lenne a turistautak táblázata.

 

Nem kell azon normalizálni semmit! A sebesség meg nem szempont.

 

És ugye, én, mint pogácsa csak kisültem a leszólt búbos kemencében.

 

Pinus Nigra Creative Commons License 2019.07.30 0 0 529

Az adatbázisnak a következő adatokat kötelező tartalmazni: p1,p2 szimbolizálja az útparamétereket, legyenek most egész számok. Kell a túraút jelzésképe, a karbantartója. Minden más mező tetszőleges. A cél minél kevesebb költséggel elvégezni egy lekérdezést, és módosítást.

Előzmény: Pinus Nigra (527)
turablog Creative Commons License 2019.07.30 0 0 528
A három "egy lépéses" művelet pont háromszorosa az optimálisnak.
Ez az egyik. A másik, hogy a módosítás hány rekordot (sor) érint, és azokat meddig tartja tárolva. A te három műveletek esetén mindhárom sikeres kell, hogy legyen ahhoz, hogy az elvárt eredményt kapjuk - azaz az utolsó lépés legvégén derül ki, hogy marad a módosítás, vagy vissza az egész, és a teljest tanzakcióra kell egy rollback.
Adatintegritást érintő kockázat továbbá az is, ha szerkesztése kivett, zárolt tájegység adatait érinti az update művelet, mert előfordulhat, hogy a jelzés áthelyezése és a kezelője egyszerre változik. Ezt a kettőt egyszerre két oldalról maratoni nem jó ötlet, azaz minden térképe objektum, pont, vonal, akármi esetén kell tudni, hogy zárolt tájegység része-e, és ha igen, és érintett a brbigyós :) módosításban, akkor végrehajtható-e az update, vagy meg kell várni a zárolás végét.
Előzmény: alnibell (525)
Pinus Nigra Creative Commons License 2019.07.30 0 0 527

Itt kérem a sémát, és az sql utasításokat
http://www.sqlfiddle.com/

Előzmény: Pinus Nigra (526)
Pinus Nigra Creative Commons License 2019.07.30 0 0 526

Sőt, p1, és p2 paraméter sincs a tuhunál, tudom :D:D:D:D

Nem az a kérdés, hogy hány lépésben tudod átírni az adatokat, hanem hogy az adatváltozás mennyi mezőt érint, ugyanis az az adatbázishasználat "költsége", te pogácsa. Egy lépésben is át lehet írni egymillió mező tartalmát is.

De tessék, ne mondd, hogy nem kapsz lehetőséget, tessék, mutasd akkor meg, milyen adatbázis szerkezetet gondolsz te.
Utána én is megcsinálom a normalizáltat, feltöltjük egyforma, 150 rekorddal, és megnézzük, kié a gyorsabb adott módosításoknál.


Egy lerágott dinnyehéjbe, hogy szokás szerint ki fogsz térni, mint mindig, ha konkrét, szakmai dolgot kell készíteni, nem csak hablatyolni.

Előzmény: alnibell (525)
alnibell Creative Commons License 2019.07.30 0 0 525

Azért az végtelenül szomorú, hogy a téma itteni felvetése után 81 nappal derült az ki, hogy a szemétdombra valónak minősített anyagomat: https://drive.google.com/open?id=1bjzeRChzBdCnpINLVK7SRc6NpdxeVRfE vagy el se olvasták az azt leszólók vagy elolvasták ugyan, de nem értették meg az abban leírtakat.

 

Abban és sehol másutt nem említettem, hogy a meglévő adattáblában tárolnám az adott turistaút karbantartójának a megnevezését. (Az tényleg egy nagy marhaság lenne, nem is foglalkoztam ezzel.)

 

Ennek figyelembevételével az alábbi feltételezés
utak tábla:
id  |túrajel|B        |R|Y|G|O|p1|p2 |karbantartó
1   |     K+|12209|  |  |  |   | 5 | 6 |VTSZKZ
2   |     K+|12209|  |  |  |   | 4 | 3 |VTSZKZ
….
150|     K+|12209|  |  |  |   |1  | 4|VTSZKZ

teljesen hamis.

Innen kezdve pedig semmi sem érvényes az írásból.

 

A felhozott változás esetében, maradva az idézett séma jelöléseinél, összesen 3 egylépéses műveletben át lehet írni a K+-t P+-ra, törölni lehet a B=12209 kódot, ill. fel lehet venni egy R=1120* kódot. Az általam sehol nem részletezett, mindenesetre megemlített, itt túraútvonalak nevű táblában is csak két adat átírása szükséges az aktualizáláshoz.

 

Minimális odafigyeléssel vagy érdemi kérdésekkel elkerülhető lett volna a kreténezés és a többi "hízelgő" jelzőzés, az itteni és korábban a TuHu területén a velem szembeni lekezelő magatartás, az ellenséges hangulat kialakulása.

 

Pinus Nigra Creative Commons License 2019.07.29 0 1 524

És ami a legszebb, hogy létre lehet hozni egy nézetet, hogy a kimenetgyártó észre se vegye, hogy megváltozott a struktúra:

Select utak_tábla.id, túraútvonalak_tábla.túraút_jele, utak_tábla.p1, utak_tábla.p2, túraútvonalak_tábla.id, túraútvonalak_tábla.karbantartó FROM utak_tábla JOIN túraútvonalak_útjai_tábla  ON id=túraútvonalak_útjai_tábla.út_id JOIN túraútvonalak_tábla ON túraútvonalak_útjai_tábla.túraútvonal_id=túraútvonalak_tábla.id

Előzmény: Pinus Nigra (523)
Pinus Nigra Creative Commons License 2019.07.29 0 2 523

A te konyhádban a konyhai eszközök vezetékei össze vannak tekeredve, a hűtőben a tojások mellett tartod a húst, a sarokban egy darab sajt száradt kopogósra, míg a joghurt kimászott a dobozából. A receptkönyved kiemelések, és bekezdés nélküli a4-es lapok, oldalszámozás nélkül, összekeverve. Bármit meg akarsz keresni, mindig muszáj átlapoznod az összes oldalt.



Adott egy túraútvonal, K+ jelzéssel, áll, 150 útból. 


általad favorizált séma:
utak tábla:
id  |túrajel|B        |R|Y|G|O|p1|p2 |karbantartó
1   |     K+|12209|  |  |  |   | 5 | 6 |VTSZKZ
2   |     K+|12209|  |  |  |   | 4 | 3 |VTSZKZ
….
150|     K+|12209|  |  |  |   |1  | 4|VTSZKZ


p1, p2 egyéb útparaméterek

normalizált séma:

utak tábla
id |p1|p2

1  |5  |6
2  |4  |3
...
150|1 |4

túraútvonalak tábla
id |túraút jele|karbantartó
11|K+           |VTSZKZ

Túraútvonalak útjai tábla
ai_id|túraútvonal_id| út_id
1     |11                 |1
2     |11                 |2
...
150  |11                 |150



Megváltozik a jelzés P+-ra, és megváltozik a karbantartó szervezet.

A te sémádban 150 rekordban kell rekordonként egy mezőt törölni (B), egy mezőt írni (R), két mezőt frissíteni (túrajel, karbantartó), azaz 600 műveletet kell elvégezni.
Normalizált sémában egy rekordban kell két mezőt frissíteni.

Előzmény: alnibell (518)
_ZE Creative Commons License 2019.07.29 0 0 522

Búboskemencében igazi a sült holmi, a gáz- vagy villanysütő az ördögtől való :-) Megfő/megsül az az étel a hagyományos körülmények között is... Indukciós főzőlap... Ugyan már, félrehúzni a "vason", ha nagyon rotyog, oszt' jól van...

Előzmény: turablog (519)
_ZE Creative Commons License 2019.07.29 0 0 521

Az, hogy működik, az egy dolog, de hogy egy meleg ételt előállító étterem mögé alkalmatlan (felhasználói igények változása) azt el kell ismerni - és nem azzal lesz alkalmas, hogy újratapasztod a búboskemencét, meg kisamottozod a tűzhelyet, vagy épp új bográcsot veszel.

Egyébként meg nincs "lerabolva" a tuhu - az, hogy a felhasználók (értve itt a térképi adatokat navigácóra használókat és a rajzolókat egyaránt) elpártoltak tőle, mert van _számukra_ jobb, kényelmesebb, rugalmasabb megoldás az nem lerablás, hanem egyedi emberek egyedi döntése, hogy mit használnak, mi nekik a kényelmesebb, jobb, szebb, hasznosabb - vagy épp megszokottabb(!) Megnézek egy BKK futárt, egy vonatinfót, meg egy rakat más, térképes alkalmazást, és nem a TuHu térképe van mögötte, hanem az OSM. Ugyanis a TuHu ilyen irányba is elég nehezen/későn próbált nyitni, ha jól rémlik. Persze infrastruktúrában is egészen más a kettő, és az is biztos, hogy a változáskezelésben lévő ordítóan nagy különbségek is a TuHu-tól elfelé vitték az embereket és a cégeket.

Az elsőség több szempontból is a TuHu-é, de az idő előrehaladtával megjelentek korszerűbb, kényelmesebb lehetőségek a funkcióinak a kiváltására, és bizony a lényegi változások hiányában sajnos azt kell mondani, hogy eszállt felette az idő, még ha az adatai... Vélhetően jó minőségűek is. Apropo, adatminőség. A TuHu-ból lehet olyan infót kinyerni, hogy melyik térképre rakott elem mikor volt legutóbb módosítva? Nem TE. hanem mondjuk egy vonallánc adott csomópontja. Mert azért amihez régen lett nyúlva, régen lett validálva, az az idő előrehaladtával -főleg terepi utak, ösvények esetében- egyre kevésbé lesz megbízható.

Előzmény: alnibell (520)
alnibell Creative Commons License 2019.07.29 0 0 520

Működik a konyha, gyere, pattogtass!

 

Eljutottunk ugyanoda, mint jó öt éve. A lehetőségek tárházának kínálatához.

Hogy hogyan működik? A példa alább, meg a Levelezési listában. Szétaprózva, új és új kérdésekkel.

Nem, ez az új konyha akkor sem, most sem kellene.

A régi? Szinte mindenben lerabolva még mindig működik, sőt újat is tud felmutatni, annak ellenére, hogy a megvalósítás terveit, alapdokumentumait elrejtették előle.

 

Utálni? Ugyan miért? Ugyanúgy elzárkózol, mint a többiek, nincs módom ténylegesen megismerni egyikőtöket sem.

Ha más fogalmat használtál volna, azzal talán egyetértenék.

Előzmény: turablog (519)
turablog Creative Commons License 2019.07.29 0 1 519
Lehet csikó sparhelen is főzni, de egy hőmérséklet és idő beállítását lehetővé tevő indukciós főzőlap azért egészen más - igaz, edényből is válogatós, de kényelmesebb rajta főzőcskézni.
Ja, hogy a villanyt is be kell vezetni...? Persze, viszont utána a használható eszközök palettája is jelentős mértékben megnő...
Ráadásul ha egy büféhez melegkonyhának akarod használni, akkor még jobban át kell dolgoznod a berendezést meg az egész konyhát.
Pedig ugyanazt az alapanyagot használod, ugyanazt az ételt főzöd. (Csak azért írtam, mert elfogyott a popcorn, meg hogy engem is utálhass :-) )


Előzmény: alnibell (518)
alnibell Creative Commons License 2019.07.29 0 0 518

Adott egy konyha, benne minden, ami a sütés-főzéshez kell. Kipróbálnál egy új receptet, megvan hozzá minden.
Nem fogod átrendezni a konyhát csak azért, mert ez a terved. Tök szükségtelen.

Aztán, ha nagy merészen mégis hozzáfognál, mert kerékpár szervizt nyitnál benne, akkor meg kiderülne, hogy a konyha eredeti tervezője eldugta valahová a terveket, s fogalmad se lenne a szükséges átalakítás lehetséges mikéntjéről.

De te csak továbbra is főzni akarsz ott, a gáz-, a víz-, meg a villanyszámlát rendesen fizeted, így nincs ok, hogy kilakoltassanak onnan.

annyi baj legyen Creative Commons License 2019.07.29 0 0 517

Hagyjátok a francba, látjátok, hogy magas neki, nem érti az egészet. Ha eddig nem fogta fel, ezután sem fogja. Egy darabig még csinálja a hülyeségeit a tuhun, aztán valakinek előbb-utóbb eléri az ingerküszöbét, és elveszik a rajzolási jogát.

 

Előzmény: alnibell (516)
alnibell Creative Commons License 2019.07.29 0 0 516

Akármennyire is erőlteti, ismételgeti az álláspontját bárki is, sőt, akinek ráadásul bennfentesként ismernie kell a valós körülményeket, annak eredménye nem lehetne más, mint az egész elvetélése.

 

Nincs kódmódosítási igény, meglévő adattábla, meglévő rekordjainak, meglévő mezői kapnának értelmezhető értékeket, amelyek alapján meglévő funkcióval lehetne egyrészt kirajzoltatni, másrészt részletes adatokat kigyűjteni az egy-egy adott mezőértéket hordozó vonalláncról. Ennyi a feladat. És semmihez nem kell változtatási céllal hozzányúlni.

Pinus Nigra Creative Commons License 2019.07.29 0 1 515

" a számítástechnika önmagáért történő felhasználását."

Ismét nagyot tévedsz. A refaktorálás biztosítja a kód karbantarthatóságát, és fejleszthetőségét, és biztosítja a az eredeti célkitűzések után jelentkező igények kiszolgálását.

 

 

"Tipikus üzleti szemlélet."

 

Ismét tévedsz, Open Source projekteknél sokkal gyakoribb a refaktor, mint céges környezetben, ahol szorít a kiadási határidő. Ha zöld az unit teszt, akkor mehet a build, még ha spagetti is az egész. Aztán amikor két év múlva átveszi egy úgy fejlesztőcsapat a kódot, akkor jön az, hogy egyszerűbb és gyorsabb, tehát olcsóbb, nulláról megírni az egészet, mint a meglévő legacy-be fejleszteni egy új funkciót.

Előzmény: alnibell (514)
alnibell Creative Commons License 2019.07.29 0 0 514

Pár mondat erejéig ...

Aki egy működő rendszert, amely minden szükséges eszközt, minden módosítási kényszer nélkül biztosítva lehetővé teszi az adott szűk területen megfogalmazott új cél elérését, de ennek ellenére 

-elkéred az adatbázismodellt

-refaktorálod

-beilleszted a nyilvántartáshoz szükséges táblákat

-létrehozod a megfelelő nézeteket, hogy a régi feldolgozók tovább működhessenek, amíg

-megírod az új feldolgozókat

műveleteket hajtaná végre rajta, az nem tenne mást, mint a számítástechnika önmagáért történő felhasználását.

 

Tipikus üzleti szemlélet.

Egyúttal a szellemiségében kísértetiesen hasonlít arra a megfogalmazásra, amely azt várta volna el, hogy a mintegy tíz év munkáját ismételjék meg a korszerűnek mondott új rendszerben.

alnibell Creative Commons License 2019.07.29 0 0 513
Előzmény: kivi000 (511)
Pinus Nigra Creative Commons License 2019.07.29 0 2 512

"mostanra már csak a szavakon lovagló hozzászólók"

 

Ja, tudod, a kommunikációban szavakat használunk. A szavaknak jelentése van. Az adatbázis például nem azt jeleni, hogy tábla. Ha rosszul használod, és szóvá tesszük, az nem szavakon lovaglás, hanem a korrekt szakmai kifejezések használata.

 

"A minap azt lehetett olvasni, hogy senkit nem érdekel az üres adatbázis mezők számossága. Akkor, mégis miért követelmény az úgymond normalizálás, ha érdektelen a kérdés?

És e téma kapcsán végül egy másik kérdés: ugyan már márciusban jeleztem írásban, hogy felhagyok a kódolási munkával, de a pótlólag felvett 5 mező máig a rendszer részét képezi. A vacillálásnak talán oka is van?"

 

 

Az ilyen szövegeidből látszik, hogy nem fogtad fel a normalizálás lényegét. A normalizálás az adatok karbantarthatóságát, bővíthetőségét, feldolgozását segíti, hogy ne egy tákolmány legyen, ami fejleszthetetlen. Az persze, nem csak a te hibád, hogy brygo mezők léteznek, hanem azé is, aki létrehozta őket, ugyanis ő sem jutott sokkal előrébb az adatbáziskezelési tudásában, mint te.

 

 

"Továbbá lényeges alapvetés volt az is, hogy a meglévő rendszeren semminemű átalakításra ne legyen szükség a nyilvántartás alapjának megteremtéséhez."

 

Ez hülyeség. Ha az adatszerkezet nem megfelelő egy célra, nem bele kell gányolni, hanem át kell alakítani. A Tuhu-ra már amúgy is évek óta ráférne a refaktorálás, csak hát nem maradt ott nagyon senki, aki el tudná végezni, mert többek közt a te idióta stílusodat megunva eljöttek onnan.  Most zajlik már egy ideje a gc.hu átírása PHP7-re, de a tuhu féle katyvaszt ki fogja rendbehozni?

Tudod, mi lett volna a menete a nyilvántartás alapjainak a megvetéséhez? 
-elkéred az adatbázismodellt

-refaktorálod

-beilleszted a nyilvántartáshoz szükséges táblákat

-létrehozod a megfelelő nézeteket, hogy a régi feldolgozók tovább működhessenek, amíg

-megírod az új feldolgozókat

 

 

Előzmény: alnibell (509)
kivi000 Creative Commons License 2019.07.29 0 0 511

akik még -hozzánk hasonlóan- szóba állnak veled

 

Előzmény: _ZE (510)
_ZE Creative Commons License 2019.07.28 0 0 510

Tehát eröltetett kérdés az, hogy főútról gyalog áttervezzen-e a navi kerékpárútra vagy sem. Aha. A tahó viselkedés ügyében meg - tán már volt is a kérdés - szoktál néha tükörbe nézni?

Tudod aki megsértődik, annak nincsen igaza, és a sértődöttség mértéke fordítottan arányos az intelligenciával. A jelzőiden nem sértődik meg senki, a fafejűséged és a szakmai ismereteid hiánya miatt meg maximum sajnálunk téged - meg azokat, akik még -hozzánk hasonlóan- szóba állnak veled.

 

Ha befejezted, akkor arra kérünk, hogy a továbbiakban _ne_ itt told a saját ötleteidet, mert mint látható errefelé sem vevő rájuk senki, ha tetszik, ha nem. Indíts egy blogot, írogass oda olyasmit, amit akarsz, olyan szinvonalon, ahogy neked tetszik, akár úgy is, hogy hozzászólásokat ne lehessen a "műveidhez" hozzáfűzni, és hagyd dolgozni azokat, akik értenek is ahhoz, amihez te csak szeretnél.

 

Előzmény: alnibell (509)
alnibell Creative Commons License 2019.07.28 0 0 509

"Ha igazad van, megengedheted magadnak, hogy megőrizd a nyugalmadat. Ha nincs igazad, nem engedheted meg, hogy elveszítsd." szellemiségét követve az alább megszólalt két fatökűvel befejezem a diskurzust.

Ennyire erőltetett kérdéseket feltevők, mostanra már csak a szavakon lovagló hozzászólók nem érdemlik meg, hogy egyáltalán szóba álljak velük. A tahó viselkedés tapasztalt mértékét már nem kívánom a továbbiakban akceptálni.

_ZE Creative Commons License 2019.07.28 0 0 508

dibéz-klipper vonalon ez nem különbözik :-D Egy dbf fájl egy adatbázis :-P

Előzmény: Pinus Nigra (506)
_ZE Creative Commons License 2019.07.28 0 1 507

Nem külön adatbázis, hanem külön tábla (1:n reláció, bár gondolom, neked a nagy rdbms gurunak, aki clipperben meg hasonlókban pallérozta rdbms témában a tudását, ez triviális...), de sebaj.

Minél mélyebbre ásnál az adatszerkezeti kérdésekbe, annál jobban látszik, hogy... khm. nem kéne. Ugyanis egyre jobban látszik az alapvető adatmodellezési ismeretek hiánya. (Ami miatt egyébként a dibéz-clipper-foxpró "guruk" gányományait az esetek egy jelentős részében elrettentő példaként szokás felhozni...)

A közreadott megoldásodról itt volt egy sommás, általában a falusi telek hátsó részében található rakást is emlegető véleményem, de inkább visszatöröltem - legyen elég annyi, hogy ha adatbázisok I. tárgy keretén belül valakinek ilyen ötlete lett volna, az tótzicsi, hogy nem jutott volna el a vizsgáig...

Előzmény: alnibell (504)
Pinus Nigra Creative Commons License 2019.07.28 0 1 506

"hanem külön-külön adatbázisban. "

 

 

Senki nem beszél külön adatbázisról. Az adatbázis, és a tábla nem szinonim fogalmak.  Az adatbázisnak részei a táblák.
Az ilyen hozzászólásaidból tudjuk, hogy nem értesz hozzá.

Előzmény: alnibell (504)
_ZE Creative Commons License 2019.07.28 0 0 505

A behajtási tilalom az adott szakasz tulajdonságaként, nem a gráf struktúrájában tárolandó. És mondd, mit teszel, ha a behajtási tilalom megszűnik?! átrajzolod a térképet? Felraksz újabb csomópontokat? Vagy az adott szakasznak a tulajdonságát módosítod? És mi van a gyalogosokkal? Mi van a kéklámpásokkal?

Előzmény: alnibell (503)

Ha kedveled azért, ha nem azért nyomj egy lájkot a Fórumért!