A munkám miatt most többször elgondolkoztam azon, hogy mennyire éri meg köztes lépésben xml-lé alakítani a külső adatokat adatbázisba fésülésük előtt. Értelemszerűen ez egy plusz lépés, és mivel 1-2 konverter úgyis használ favágó módszereket, talán nem is lenne nagy különbség, ha közvetlenül a beolvasó részbe írnám bele a database commit-ot is. (Az egyik konverter pl. egy lib nem egyértelmű függvényét írja át explicit még kevésbé egyértelműre, és ez a duplán nem egyértelmű függvény szolgáltatja az effektív adatokat. :))

Ugyanakkor a köztes nyelv segít ezeket a nem hordozható kódrészeket elkülöníteni azáltal, hogy az adatfolyam többi részét függetleníti tőlük, és amit most még fontosabbnak érzek, az a külső eszközzel történő validálás lehetősége. Igaz, hogy programon belül is lehet ellenőrizni, hogy egy-egy adat pl. 5 számjegyből áll, vagy csak ilyen-olyan betűket tartalmaz-e (kódoknál), és habár leírva mindez elég triviálisan hangzik, az implementáció egyáltalán nem feltétlen lenne az. Ugyanis:

1. ezeket a szabályokat a kezelhetőség érdekében előbb-utóbb úgyis külön részbe, modulba mozgatná az ember,
2. a szabályok valószínű mindig függenének az adatot tartalmazó adattípus (class/type) tulajdonságaitól is, még dynamic typing-ot használó nyelvekben is,
3. és a 2. problémát nem biztos, hogy 100%-osan át lehetne hidalni pl. duck-typinggal, már pedig a dokumentum vagy legyen valid vagy invalid, nem pedig ‘nem tudom’ vagy ‘null’, vagy hogy jobban érthető legyen: invalid, mert nem ismerem fel az egyik adat típusát (pedig amúgy lehet, hogy valid adatot tartalmazna).
4. Végeredményben az adatszerkezethez saját, nyelven belüli api-t kéne kialakítani a hosszútávú használhatóság érdekében, és még ha a nyelv külön támogat is ilyen ellenőrző feltételeket, akkor is csak a nyelvi környezeten belül lenne mindez elérhető – adott esetben az adatbázisrésszel együtt csak.

Az xml persze megoldás lehet ezekre a problémákra, hiszen különálló, külön értelmezhető dokumentum/api, amihez már léteznek kiforrott validáló eszközök. Azt rémlem, hogy használata kiszűri a GIGO lehetőségét, valamint függetleníti az adatbázis mechanizmust a konverterektől, úgyhogy ha majd le akarom cserélni az adatbázist, elég csak egy xml beolvasót írni, ami lényegesen egyszerűbb, mint hard coded adatok közt nyúlkálni. Legalábbis ezt hiszem. :)

Ezenkívül egyéb haszna is lenne, de ezek most a legközvetlenebb gyakorlati dolgok, úgyhogy most csak erről írtam, és nem a még távolabb lévő utópiáról. :)

Mint mondtam már jó pár embernek, új munkaköröm van, és szerencsére ez most több programozást jelent. :)

Elkezdtem adatkonvertereket írni, illetve még csak egyet, mert szándékomban áll a bejövő adatokat xml-be rakni, hogy később automatikusan validálni lehessen a konvertálások eredményeit. Persze, ahogy akartam, hogy működjön az xml output, ahhoz nem találtam megfelelő module-t…

Mivel a legtöbb adat rekord szerkezetű, ezért ahelyett, hogy valami giga-DOM-ot akarnék felépíteni, inkább egyfajta fordított SAX-parser kellett volna, ami képes soronként, egymás után, on-the-fly írni az xml-t.

Egyszóval írok magamnak egyet, csak ezzel is elmegy 1-2 nap. :)