Szakdolgozat adatfájlok

Re
Írtam már hogy milyen funkciói lesznek a szakdogának, most jön némi háttér információ. Úgy gondolom, hogy mai PDA-knak nem kottyan meg pár száz kilobyte-nyi adat a memóriában, ezért minden adatot betöltök induláskor a memóriába. Amikor épp nem fut a program az információk 4 fájlban vannak. A fájlokat egy zip-fájlban fogom össze, hogy könnyebb legyen a mozgatásuk.
Minden osztály külön ID-vel rendelkezik. Először a fájlban elhalyezett sorrendre hagyatkoztam, de rá kellett jönnöm, hogy a módosítás és törlés azokban a fájlokban nagy gubancot fog okozni, így a picit több helyet, de sokkal nagyobb stabilitást adó megoldás mellett maradtam.
Külön fájlban tárolom az összes osztály "hétköznapi" nevét.. Kezdés képpen letárolom a járatok számát, majd soronként elválasztva a járat ID-jét és a nevét. Utána hasonló struktúrában a megállókat, a csoportokat, az érdekes helyeket majd a végén a jármű típusokat.
A menetrend külön fájlban tárolódik, ez már nem olvasható csak úgy, mert csak bináris számokat tartalmaz. Járat centrikusan tárolom az adatokat, ezért a fájl elején a járatok száma szerepel, majd utána következik az első járat id-je. Ezután azon megállók szám, amiket a járat érint. Fel is sorolom őket, a következő megállótól való távolsággal együtt. A megállók után megadom hányféle menet nap van, majd h az első menetnaphoz hány indulási időpont tartozik. Letárolom az időpontokat, majd jön a következő menetnap. Ha a végére értem, jöhet a második járat ID-je és így sorban egészen az utolsóig.
A megállók csoportjai egy másik fájlban vannak. Szintén binris, de nem ilyen bonyolult az olvasása. Először megint csak a csoportok száma, majd az első ID-je, és hogy mennyi megállót fog össze és a felsorolásuk. Utána jön a második megálló ID-je stb stb...
Az utolsó fájlba maradtak a koordináták. Koordinátái egyébként a csoportoknak, a megállóknak és természetesen az érdekes helyeknek vannak. Ezeket is ID-jükkel tárolom.
Véleményem szerint - persze elfogult vagyok - kellően stabil és egyszerű ez a tárolási módszer, de vannak hiányosságai. Ezek a hiányosságok olyanok, amik nem veszélyeztetik a szakdolgozat sikerét és nem csökkentik az értékét, ugyanakkor pótlásuk bonyolítana a kódon és csökkentené az átláthatóságát. Kicsi az esély, hogy elsőre működő képes kódot tudnék írni, a hibák javítása sok időt elvenne és fenn állna a veszélye, hogy észrevétlen hiba marad benne.
Tehát a hiányosságok:

• Pazarló tárolás, a koordináták kivételével mindehol 32 bites inteket használok, mert az a legkézreállóbb. Az időpontok, és az ID-k tárolására szerintem elég lenne bőségesen 16 bit is, ami jelentősen csökkentené az adatfájlok méretét. Persze relatívan nézve... 500kB-ot ha le tudok csökkenteni 250 kB-ra az nem rossz, de most egy gigás kártyán fel sem tűnik... Ha a program belső szerkezetét is átvariálnám 32 bites számokról 16-osra valamennyit csökkenne a memóriában lévő adat, de megint csak nem tartom jelentősnek, hogy ezzel szöszöljek.
• Az időpontok tárolását is lehetne módosítani. Minden időpontot külön értékként tárolok. De a városi közlekedére jellemző, hogy a járatok egymást adott időközönként követik. Ha mondjuk egy járat 8-tól este 6-ig 5 percenként indul, akkor az az én tárolási rendszerem szerint 96 bejegyzés. Ha csak azt tárolnám, hogy "8-tól 6-ig 5 percenként" az 3 bejegyzés lenne. Persze ha valamelyik járatnak sűrűn vátozik a követési ideje, akkor ott elveszik ez az előny, sőt! Ha mondjuk a busz menerendeje olyan, hogy a páros járatok 5 a páratlanok 10 perc múlva követik az előzőt, akkor egy buta algoritmus képes lenne 3-szor több adatot generálni, mint a jelenlegi. Persze választhatóvá is lehetne tenni, hogy legenerálja mindkét verziót, aztán eldönti h melyik gazdaságosabb.

Ezek a pótlások olyanok, hogy szép és elegáns megoldások lennének, de talán fel sem tünnének a különbségek a felhasználónak viszont a megvalósításuk eltartana pár napig biztosan.