Nem kell olvasni, hogy meg vagy sértődve: elég a kommunikációdat figyelni, arról ordít, hogy egy sértődött alak vagy, aki szerint mindenki hülye, (csak ő a helikopter), és dafke megtiltja bárkinek, hogy az övéhez hasonló baromság jusson az eszébe.
A "Hónapokkal ezelőtt lemondtam róla." akkor lenne igaz, ha nem hoztad volna ide is a szarodat, már bocsánat. Annak, hogy az "öt kódmező" még megvan, n+1 oka lehet: a tuhu-ról el tudom képzelni azt, hogy "select *" kimenete megy egy tömbbe, ahol nagyon nem mindegy, hogy a táblának hány oszlopa van. Mondjuk az ilyen kódot dettó automatikusan visszadobtam akár oktatásról, akár code review-ról volt szó.
Hogy ki találta ki ezeket a mezőket az adott táblában és miért, az jó kérdés, nekem úgy tűnik, hogy azért ott sem volt 100%-ban rendben minden a normalizálás témakörében...
Fölösleges volt "megtiltanod", ugyanis értelmes junior fejlesztő sem csinálna ekkora ortopéd baromságot, amit te összekókányoltál, akkora szakmai tulok, amekkora te vagy, meg szerintem évszázadonként ha egy születik, akkor sokat mondok, úgyhogy arra sincs esély, hogy valaki hozzád hasonló szakmai nulla nekiálljopn lemásolni a baromságodat.
Úgy van, megtiltottam a felvázolt és azzal konform módon történő megvalósítást. Ezt csak én tehettem meg. Meg volt hozzá az indokom és az alapom.
Az meg tapasztalat, ha valamivel türelmesen, kellő figyelemmel, viszonylag hosszú időn át kellene foglalkozni, arra nincs vállalkozó.
Az általános szemlélet az, hogy azonnal szeretné látni a munkája eredményét a közreműködő. Ez volt az egyik indítéka az ún. új raszteres forszírozásának. Hogy eközben más munkája az értetlenség és az érdektelenség folytán sérül, ugyan kit érdekel?
Biztos az emtéesz le akarja nyúlni az ötletedet, és lefizette a tuhut érte, pedig te MEGTILTOTTAD, hogy bárki felhasználja, vagy hasonló kódolást készítsen :)
Vagy az is lehet, hogy a tuhu jelenleg olyan hely, ha ledobsz a sarokba egy adag lomot, évek múlva is ott hentereg.
Mindkettőre van esély, no,de melyik a valószinűbb ?
Úgy tűnik, képtelen vagy felfogni vagy ha igen, akkor meg szándékosan nem veszed figyelembe, hogy a javaslat közreadásakor semmi esély nem volt arra, hogy a meglévő adatszerkezet módosítását eredményesen kezdeményezzem. Ez a helyzet ma is.
Hiába emlegettek új táblákat, módosult adatszerkezetet, járhatatlan út.
Ami meg a jól irányzottat illeti, ha a közelemben lennél, már megkaptad volna.
Az elképzelésed olyan sok-sok éves specifikáción alapul, amiről nem csak azt nem tudod, hogy bővült-e, hanem még azt sem, hogy érvényes-e egyáltalán. A technikai megvalósítása szakmailag tré az adatok tárolása miatt, a bővíthetősége, pont az elcseszett adattárolás miatt csak kókányolással lehet. Ennek ellenére meg vagy sértődve, hogy senki nem akarja használni :)
Az adott táblába nulla darab mező kell, egy másik táblánál kell mondjuk három: vonal_id, jelkod, karbantarto_id, egy plusz táblába meg mehetnek a karbantartó szervezetek adatai - utàna csak jól irányzott :-) select-ek kérdése az egész.
Ja, ezzel az öt darabos korlát kuka, a rögzíthető jelzésképek számára vonatkozó korlát kuka (az igazán szép megoldásban a jelkod helyett szín és jelalak_id mezők vannak, ez utóbbival kapcsolva a jelalakot ténylegesen megadó táblához)...
Tudtam és le is írtam, hogy mindenre lehetséges eset kezelésére nem alkalmas a választott módszer.
Így fogalmaztam a BRYGO ismertetőjében:
"Ahhoz, hogy minden lehetséges színű és jelalakú út megkülönböztethetően leírható legyen, öt mező nem elégséges, elsősorban a többszörös fonódások miatt. Viszont, igazodva a MTSZ ajánlott kódrendszeréhez, ahhoz elég, hogy a MTSZ és a megyei szervezetei által kezelt utak egyedileg kódolhatók legyenek."
Rosszindulattal fűszerezett primitívség kell ahhoz, hogy ez mint új negatív észrevétel az utóbbi pár napban terítékre kerüljön.
Te tényleg marhára nem fogod a relációs adatmodellek alapjait. Sem. Ha kiderül, hogy pl. a kerékpáros utakat is kezelni kell, akkor újabb mezőt veszel fel?
Bár, ha megkérdezném, hogyan jött ki ez a szám, akkor ugye ismét csak terelnél, igaz? Vagy mégis megkérdezem: hány darab, és melyik túrautak esnek a maradék 0.05%-ba?
"Te még valószínűleg az iskolapadot koptattad, amikor egy vállalati osztály szerződéses és pénzügyi állományai már egy relációs adatbázisba voltak szervezve. "
Ez nagyon releváns információ volt ismét :D
"Ti itt azon rugóztatok, hogy nem tudom, mi a különbség az adatbázis és az adattábla között? "
Értitek? Semmit nem értesz vagy nem vagy hajlandó tudomást venni a lényeges körülményekről.
Az meg igazán nem érdekel, hogy rólam mi a véleményed. Hiába jelzed folyamatosan, nem ide tartozik.
Újdonság semmi nem ért. Lekezelő fölényeskedés annál több. Szinte más sem.
Te még valószínűleg az iskolapadot koptattad, amikor egy vállalati osztály szerződéses és pénzügyi állományai már egy relációs adatbázisba voltak szervezve.
Ti itt azon rugóztatok, hogy nem tudom, mi a különbség az adatbázis és az adattábla között? Nagyjából most is ez megy. Legyetek büszkék magatokra!
De egy vonalhoz miért csak vb négy plusz egy darab öt karakteres kódszó rendelhető? A táblában ennyi oszlop van nem indok, hanem szakmailag védhetetetlen kifogás.
Tudom, plusz táblánál kiemelve az export/import funkciókat is ki kellett volna reszelni megfelelőre...
Konkrétumok? A BRYGO-kódolás anyagában minden le van írva. Az is, hogy alapvetően szükségtelen lett volna az öt új mező beépítése a vonalas objektumok adattáblájába, az is, hogy ennek ellenére miért lettek mégis beillesztve, meg az is, hogy hogyan nézne ki az a táblázat, amely a túrautak egyedeiről rögzít részletezett információkat. A tegnapi idézetem ez utóbbira vonatkozik: https://forum.index.hu/Article/viewArticle?a=152149939&t=9219453
Ezek együtt már azt is elárulják, hogy mi a reláció közöttük. És ez az egész egy anyagban van leírva.
Még hogy túltárgyaltuk volna. Ahhoz az kellett volna, hogy megértse a partner a részletesen leírt gondolatmenetet.
Ez elmaradt, jött helyette egy olyan közbevetés (túraút fenntartó), ami viszont az anyagban sehol nem szerepel, és az lett erőltetve.
Persze, hogy nem használja senki. Aki használhatná, közölte, ő ebbe nem kíván energiát fektetni. Másfelől inkább hallgat róla, nehogy változtatni kelljen a meglévő ilyen-olyan adathalmazán.
A turisták döntő hányada számára meg érdektelen a felvetés.
Pont ugyanúgy, mint amikor arról volt szó, hogy adatvesztés nélkül egyszerűsítsük a paraméterkészletet, egyúttal biztosítsuk a jobb térképi megjelenítést. Dolgozni kellett volna vele, hát elmaradt. Aki meg a térképet böngészte csupán, annak meg teljesen mindegy volt, hogy miként született az előtte lévő térkép.
Egyelőre nincs következő téma. Éppen elég volt az ócsárlásból a gráfok élei és csúcspontjai és a fenti téma kapcsán.
Változás majd akkor lehetséges, ha a TuHu illetékese törli az adattábla fent említett öt új mezőjét, megsemmisítve ezzel az eddig belefektetett munkát. Vagy ha rájön, hogy igenis érdemes lenne vele foglalkozni. Ez utóbbi viszont követelményt is támasztana a közreműködőkkel szemben.
Vannak a vonalas objektumok, amik mindegyike kap öt új mezőt, ami önkényesen a meglévő négy (ez nem igaz, mert van lila és fekete színű jelzés is) szín meg az ebből a kategorizáláyból kilógó "egyéb" tulajdonságot tartalmazza szigorúan öt karakteren.
Ja, nem, az eredeti ötlet lehetett ez, a mezők elnevezése nem kapcsolódik bennük "kódolt" színhez.
Pontosabban nem egy relációt, hiszen az öt katakter azonosítja a tájegységet (a vonalas objektum - tájegységhez kapcsolási szerintem máshol is megvan, hiszen adott te. objektumok most is leválkgathatóak), a következő két karakter a jelzés színét és alakját tartalmazza, plusz van egy sorszám is.
Többszöri elolvasása után sem mondhatok mást, csak azt, hogy ha valaki adatbázisok tárgykörben 20xx-ven ilyet tett volna le az asztalra féléves beadandó gyanánt, az nemhogy a vizsgán nem ment volna át, az aláírást sem kapta volna meg.
Valós fejlesztés esetén még vélhetően a HR-re bíztuk volna az illető további sorsát, mert ilyen "minőségű" produktumra képes fejlesztő cégen belül tartását ép eszű felelős vezető nem engedheti meg magának.
S mivel az alább is emlegetett használhatatlan gányolásnak a fenti idézet szerinti adattábla felépítés az alapja, nincs értelme sem magyarázkodni, sem megismételni a korábbiakat.
A tegnapelőtt este linkelt kép igazolja, hogy működik, működhetne a dolog, de ennek ellenőrzéséről meg lemondtál.
Nos, valahogy úgy néz ki a dolog, hogy némi bizonytalanság irattatja a kérdéseket.
Válaszként legyen elég annyi, hogy a TuHu jelenlegi adatbázis szerkezete semmiben nem változna.
Leírod már végre azt az adatsémát, vagy nem? Ne köntörfalazz, térj a lényegre.
Ha nem, akkor csak egy pofázógép vagy, aki a saját hangjába szerelmes. Szóval várom milyen adattáblákat használsz, azokban milyen elnevezésű mezőkben, milyen adatokat tárolsz, és ezek milyen relációban vannak egymással. Ennyire csak kiterjed a tudásod? Ha meg nem, akkor miért erőlködsz?
"A téves feltételezésre visszatérve, többen is kértük, hogy mutasd meg az általad használt adatbázis sémát, ..."
Csak erre, a többi számomra teljesen érdektelen, alapvetően nem más, mint terelés az egyre durvuló társalgás eredeti témájáról.
Aki az alábbi sorban megfogalmazott adattábla felépítést leírta és ennek alapján írt véleményt
"id |túrajel|B |R|Y|G|O|p1|p2 |karbantartó"
az elsősorban arról tett tanúságot, hogy egyszer se próbálta tüzetesen átolvasni, helyesen értelmezni az elé tárt anyagot.
Erre is három hónapot kellett várni. S mióta nyilvánosságra került ez a teljesen elhibázott feltételezés, nem történik más, mint a terelés egyéb más felemlegetésével. Ugyanúgy fölényeskedve, mint addig.
Továbbá, ha a vitapartner - mit vitapartner? - nem hajlandó kiindulási alapként tudomásul venni azt, hogy azzal a nem elhanyagolható feltétellel kellett megoldás találni, amely szerint semmilyen változtatási igény nem léphet föl a meglévő rendszer egyetlen elemén sem, akkor vele nincs miről beszélni. Akkor minden kérdése irreleváns.
(Ezt fejezte ki a szűk mozgástér. Persze ez is ki lett fordítva, szokás szerint.)
"azokat nem lehet módosítani igény szerint. Az ArcGIS-nél, ahol úgymond minden megvan, ugyanez a helyzet."
Mi van? Olyan lekérdezést ír mindenki Arcgisben, amilyet akar. Te tuti láttál valami Esrti Leaflet térképet, és azt hiszed, az az Arcgis :D:D:D:D:D:D:D:D
Na, akkor még egyszer, mert szokás szerint nem néztél semminek utána, ami itt le lett írva, csak a szád habzik: Az Arcgis egy GIS ökoszisztéma. Bele tartoznak a desktop programok, terepi adatfelmérők, webes adatbázisok, vektoros, raszteres térképek. Úgy működik, hogy megtervezik a felmérendő adatok tárolását, a szükséges kimeneteket, majd elkészítik a lekérdezéseket. Van, amiből interaktiv vektoros térkép lesz, van amiből kördiagram, van, amiből print, van amiből táblázat. És mindez az Arcgis által nyújtott eszközök felhasználásával. És olyan lekérdezést készítesz, amilyet akarsz. Ha azt akarod, hogy pirossal mutassa a térkép az egyik festő által festett utakat, kékkel a másikat, akkor olyat csinálsz. Ha azt akarod, hogy mutassa egy adott túraútvonal festésekor készített fényképeket, akkor olyat csinálsz. Ezt hívják térinformatikai adatbázisnak. Belehúzhatsz külső adatokat, háttértérképeket, számoltathatsz, minden a felhasználón múlik.
"Az MTSZ 2010-ben a megyei szervezetei kezelésében lévő túrautak egységes nyilvántartásának kialakítására tett felhívást. Én a magam módján erre adtam egy megoldási javaslatot"
És eddig mindenki megállapította, hogy gány, és használhatatlan. Nem érdekelte sem az MTSZ-t, sem a Tuhu-t, és itt sem állt rajtad kívül mellé senki. De te tovább pörögsz rajt, mert milyen dolog, hogy te minden érdek nélkül megcsináltad, és mi az hogy nem esnek hasra a te hatalmas teljesítményed előtt?
"négy majdnem teljesen feldolgozott TuHu-tájegységnél egyetlen olyan eset se fordult elő, amely akadályozta volna a kódolási munkát."
Levezettem idén eddig kb. 15 000 kilométert, egy olyan eset sem fordult elő, amikor szükségem lett volna a légzsákra.
"Továbbá, kénytelen voltam a meglévő mozgásterem keretei között mozogni"
Ebben igazad van, a mozgásterednek valóban szűkek a keretei. De ezen tanulással lehet segíteni ;)
"normalizálás megérne egy értelmes vitát"
Nem, a normalizálás nem vita kérdése.
"Annak felvetése ugyanis a már többször említett, kényszerűen napvilágra hozott téves feltételezés folyománya, az ott felhozott módosítási példával együtt. "
Fogadjunk, hogy hivatalnok voltál/vagy :) Tudod mi a különbség te és Joyce Carol Oates között? Hogy utóbbi tud olyan két oldalas összetett mondatokat írni, hogy egy lendületes, élvezettel olvasható szöveg marad, ellentétben a te izzadságszagú kreálmányaidtól, ahogy próbálsz szabatosan fogalmazni, de csupán egymást után hányt szavak összessége lesz az eredmény. A téves feltételezésre visszatérve, többen is kértük, hogy mutasd meg az általad használt adatbázis sémát, ne magyarázgass, hogy te nem ilyenre gondoltál, meg nem ez van a blogodban leírva. Mivel a tuhu MySQL-t használ, jöhet abban, de szerintem elboldogulunk más nyelvekkel is :) Sőt, jöhet pszeudo-kód is, átírom szívesen SQL-re :)
Vagy már megint konkrét dolgot kérek, igaz, ilyenkor jön a durci :D
Az MTSZ 2010-ben a megyei szervezetei kezelésében lévő túrautak egységes nyilvántartásának kialakítására tett felhívást. Én a magam módján erre adtam egy megoldási javaslatot. Eleve nem vállalkoztam arra, hogy az összes, a különböző társadalmi szervezet által kitűzött, felfestett útvonalat is kódoljam.
Ugyanakkor tapasztalatból tudom, hogy négy majdnem teljesen feldolgozott TuHu-tájegységnél egyetlen olyan eset se fordult elő, amely akadályozta volna a kódolási munkát.
Továbbá, kénytelen voltam a meglévő mozgásterem keretei között mozogni.
A sokat emlegetett normalizálás megérne egy értelmes vitát, de a mostani körülmények között semmiképp. Annak felvetése ugyanis a már többször említett, kényszerűen napvilágra hozott téves feltételezés folyománya, az ott felhozott módosítási példával együtt. https://forum.index.hu/Article/viewArticle?a=152035950&t=9219453
Értelmesen, a felek kölcsönös tisztelete mellett hajlandó lennék eszmecserét folytatni arról, hogy hol érdemes tárolni egy vonallánc szakasz hovatartozását, továbbá, hogy miféle módosulások a gyakoriak, s hogy ezek az adattáblában, ill. táblák melyikében követelnek meg egyedenkénti beavatkozást. Ennek a lehetősége elveszett. Nem miattam.
Akár tetszhetne is az esetenként előbukkanó önellentmondás. Az én javaslatommal szemben az egyik negatív észrevétel az volt, hogy a mások által megírt kódokhoz nem lehet hozzáférni, azokat nem lehet módosítani igény szerint. Az ArcGIS-nél, ahol úgymond minden megvan, ugyanez a helyzet.
Azzal kezdted, hogyha valami nem jó az összes lehetséges variáns kezelésére, akkor az arra a feladatkörre alkalmatlan. Ugyanakkor, ha egy applikáció az indított lekérdezésekre a "Nincs elérhető információ" választ adja, akkor az csak játék, amelyet lehet mutogatni, csak hasznos információt nem lehet kinyerni belőle.
Már ott bukott a javaslatod, hogy a tudott korlátait nem az adatmodell rendes kialakításában, hanem a lehetőségeiből kilógó esetek külön kezelésében látja.
Innentől kezdve minden csak gittrágás: a jelenlegi adatstruktúra erre a célra gyakorlatilag nem alkalmas. Meg lehet erőszakolni, de egy nagyobb változás/bővülés a jelzésekben, és máris lehet újragondolni/újragondolni az egészet. Mint anno amikor kitalálták, hogy az évszámot elég kétjegyű számként tárolni... Aztán 1999-ben jöttek a tákolások, hogy az 1900 és 2000 megkülönböztethető legyen.
