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.)
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.
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.
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.
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...
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ó.
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.
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 :-) )
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.
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.
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.
" 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.
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.
"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
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.
"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.
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...
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á.
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?
Ha valamiben nem vagy biztos, nem győződtél meg róla, akkor mi a fészkes fene alapján állítod, hogy azon műveleteket kellene végrehajtani?
Ha azt állítja valaki, hogy egy-egy vonallánc szakasz jelzett turistaúthoz tartozását - egyfajta tulajdonság - nem az egyedi azonosítóval bíró vonallánc szakaszok adatbázisában kell(ene) tárolni, akkor azzal egyúttal azt is állítja, hogy a vonallánc szakasz településen belüli nevét vagy az útvonal számát - másfajta tulajdonságok - sem abban kell(ene) tárolni, hanem külön-külön adatbázisban.
Ugyan meddig ragozod még, amihez amúgy soha semmi ráhatásom nem volt és most sincs? Azt viszont én továbbra is határozottan állítom, hogy a közreadott megoldási javaslatom alkalmas az abban megfogalmazott cél elérésére. Csak akarni kell(ene) a megvalósítást.
Valóban nem kötelező a kerékpárúton közlekedni bicajjal, ha az a bizonyos kerékpárút Keszthelynél van, az illető meg Győr és Győrszentiván között tartózkodik a 813-as számú út környezetében. Ott viszont táblák sokaságával határozottan tiltják, már csak azért is, mert mellette halad néhány 10 m-rel Ny-ra a számára kijelölt út.
Hogy ki jár tévúton, azt már többszörösen bizonyítottad. Ne rombold tovább a képet, elég vacak már így is!
"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?" - ha ezt nem tudod (nem, nem az, hogy takarékosabban bánjunk a rendelkezésre álló tárterülettel...), akkor tényleg illene utánanézni a normalizálásnak, meg annak, hogy miért és mire jó, miért kell. Persze ha igaz, hogy a tuhu valóban egy táblába lapátol be mindent, amiben azért nem vagyok annyira biztos.
Szerinted nem tartózkodhat kerélpáros, illetve gyalogos, azonban a kresz meg alnibell közlekedési szabályinak a helye nem az útvonaltervezés alapját képező gráf felépítésében, hanem az élek, illetve a csúcsok tulajdonságaiban van. Kerékpáros például közlekedhet azon az úton, merthogy - ha már a kreszt citáltad - nem kötelező a kerékpárúton haladni kerékpárral, ez az egyik, a másik meg az, hogy ha az adott úton mégis tilos lenne kerékpárral közlekedni, akkor is le kell tudnia a tervezőnek vinnie a lehető legrövidebb úton olyan útvonalra, ahol már igen, azaz megint csak úgy áll a dolog, hogy kell az a nyamvadt csomópont, de sebaj, erre is mondani fogsz valamit, tudom, amivel persze maximum a hozzánemértésedet fogod egyre jobban bizonygatni (tudod, már nem először írják le neked, hogy át kéne gondolnod, hogy vajon tényleg mindenki szembe megy az autópályán, vagy csak te, egyedül?)
S mielőtt újra elővezetnéd: a jelölt kezdőponton, szabálykövető magatartást feltételezve, nem tartózkodhat sem gyalogos, sem kerékpáros. (A magyarázat a kivonaton megtalálható.)
Akkor folytassuk! ("Kis kreténke"; azt hittem már felnőttél.)
- A TuHu vonalainak csak egy adattáblája van, s legfeljebb arról lehet szó, hogy a rekordjainak egy része hordoz kódot tartalmazó mezőt. És itt egy kicsit álljunk meg.
Az adatbázis rekordok mindegyike tartalmaz K= nevű paramétert, ami mellé később beépítették a Turamozgalom= paramétert. Ez utóbbi bevezetése redundanciát eredményezett azoknál a vonallánc elemeknél, amelyek a három nevesített, országos jelentőségű K sávjelzésű úthoz tartoznak. OK, ez nem okozott problémát senkinek.
Aztán jött egy ötlet, elkezdődött a megvalósítása és máris gubanc adódott.
Ha egy útnak lehet paramétere, hogy hozzátartozik-e a három turistaút valamelyikéhez, akkor ugyan miért ne lehetne a rekordok egyébként is meglévő ugyanezen mezőjében tárolni azt, hogy mely másik kék színű, de más jelalakú úthoz tartozik? Végtelenül egyszerű kérdés, csak a tiltásnak nincs semmi indoklása. (Illetve van, a szent teheneket ne bántsa senki!)
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. Nem a nyilvántartásának, arra eleve nem vállalkoztam.
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?
- Előbb kérdeztem, majd várakozás után léptem. Szerintem nem hibásan. Az extra feltételeket tartalmazó útvonaltervezés meg nem érdekel, fölösleges bele energiát ölni.
- A velem szemben nyíltan ellenségesen fellépőknek semmi alapjuk nincs sem elvárni, sem megkövetelni a prezentációt. Némi utánajárással majd mindenkinek adott a lehetőség az állítás helyességének megállapítására.
- Még most is ott tartasz, hogy nem olvastad el az észrevételezett hivatkozáshoz tartozó, közvetlenül mellette lévő pár kiegészítést. Bővebb felvilágosítást az ún. új raszteres generálási módjáról a jelenleg magát illetékesnek tekintőtől kaphatsz.
Alkalmatlanság? Ki állítja ezt? Van egyáltalán valami is, ami általa előmozdította TuHu-t?
"Honnan veszed, milyen tapasztalatok alapján állítod, hogy ne lennék tisztában az adatbázis normalizálás mikéntjével, egyáltalán a céljával?" - elég a témához kapcsolódó megnyilvánulásaidat, vagy akár a brbigyó vagy hogy a búbánatban hívod agyszüleményedet megnézni...
"Valóban nem tartottam jónak az ún. új raszteres erőltetését. Elsősorban azért nem, mert folyamatosan terhelte az adatbázis szervert, továbbá, mert hibákkal terhelt volt és van még most is." - hajrá, a terhelést megfelelő adatszerkezettel, indexekkel, normalizálással és denormalizálással, meg korrekt workflow alkalmazásával az esetek döntő részében lehet csökkenteni.
Miért nem vetetted bele magad az optimalizálás ezen részébe? Ez a nagy tudásodnak val feladat, nem néhány(tucat) vagy akár néhány száz szerinted fölöslegesnek vélt csatlakozási pont kiszórása, vagy épp újabb, érdemben senki által nem támogatott/használt mezőkkel telerottyantani a DB-t...
"itt most a TuHu fórumának folytatása megy, az ott kialakult módon" - onnan ha jól tudom, téged kivágtak, és a korodnál fogva ismerned kéne azt az elvet, hogy máshonnan áthozni vitát nem illendő, hogy finoman fogalmazzak. És biza te hoztad át onnan ide a számodra sérelmes témát, és itt folytatod...
Az elején a tervezésről _is_ szó volt, ugyanis - bár úgy tűnik, nem bírod felfogni - a tervezéshez kell a gráfban közös csúcsnak lenni ahhoz, hogy a két él bekerülhezzen a tervezett útvonalba.
