SQL::Translator, az SQL mindenes
Pár évvel ezelőtt írtam egy függvényt, mely egy SQL kifejezést átalakított egy olyan SQL kifejezéssé mely futtatásakor az előbbi kifejezés lekérdezésekor keletkező sorok számát adta vissza eredményül. Vagyis egy
Az SQL::Translator modul egyelőre még csak az SQL definíciós részét kezeli (CREATE, ALTER, DROP), de már így is számos funkcionalitással bír. A modul telepítése után kis szkriptek is rendelkezésünkre állnak, melyekhez nem szükséges Perl tudás.
A modul parser és producer részekből áll, s gyakorlatilag adatbázisszerű formátumok, leíró nyelvek, stb. között képes konvertálást végezni, egy belső objektum modellt kialakítva. A következő parser-ek állnak rendelkezésünkre:
A modul telepít egy parancssori szöveg-szöveg átalakítót, egy sémák közötti különbségeket felfedező, s SQL utasításokkal leíró programot, diagramm generátorokat, a
A program honlapján pár kimeneti diagramm és telepítési leírás is található. Érdemes megnézni közelebbről!
■ select * from tabla
kifejezésből select count(*) from tabla
lett (és bonyolultabb esetekben is működött). Nem volt egyszerű, nem működött mindig, de sikerült kihoznom egy olyan verziót, amit a gyakorlatban használható volt. Itt azonban az SQL::Translator Perl modul, mely jóval többet és azt jóval használhatóbban tudja az én egyszerű kis kódomnál (bár egy kicsit másról szól, ez pont nem valósítható meg benne - még). Nem csak Perl programozóknak érdemes egy pillantást vetniük erre a modulra, mely konvertálni képes különböző SQL dialektusok között, diagramokat tud készíteni, Excel táblákat használni, XML formátumokat írni, olvasni, stb.Az SQL::Translator modul egyelőre még csak az SQL definíciós részét kezeli (CREATE, ALTER, DROP), de már így is számos funkcionalitással bír. A modul telepítése után kis szkriptek is rendelkezésünkre állnak, melyekhez nem szükséges Perl tudás.
Egy kimeneti lehetőség
A modul parser és producer részekből áll, s gyakorlatilag adatbázisszerű formátumok, leíró nyelvek, stb. között képes konvertálást végezni, egy belső objektum modellt kialakítva. A következő parser-ek állnak rendelkezésünkre:
- Oracle
- MySQL
- PostgreSQL
- SQLite
- Sybase
- DBI-MySQL
- DBI-PostgreSQL
- DBI-SQLite
- DBI-Sybase
- Microsoft Excel táblázatok
- XML-SQLFairy (natív XML)
- xSV (valamivel elválasztott szöveges fájlok)
- Storable (szerializált séma objektum)
- YAML (szerializált séma objektum)
- Oracle
- MySQL
- PostgreSQL
- SQLite
- Sybase
- HTML
- POD
- ClassDBI
- Diagram: egyed-kapcsolat diagrammok libgd-vel
- GraphViz: egyed-kapcsolat diagrammok GraphViz-zel
- TTSchema: "bármilyen" szöveges fájlok sablonnal
- Storable: szerializált séma objektumok
- YAML: szerializált séma objektumok
- XML-SQLFairy: natív XML formatum
A modul telepít egy parancssori szöveg-szöveg átalakítót, egy sémák közötti különbségeket felfedező, s SQL utasításokkal leíró programot, diagramm generátorokat, a
mysqldump
-hoz hasonló célú, de akár Oracle-lel is működő programot, illetve egy webes frontendet az összes funckió eléréséhez.A program honlapján pár kimeneti diagramm és telepítési leírás is található. Érdemes megnézni közelebbről!
vélemény
Az egyik, hogy nagyon jó lenne ilyesmi PHP-ben is. A PEAR-es DB_DataObject képes rá bizonyos szinten, a 2004-es dunaújvárosi előadásomban mutattam is rá sok példát. Ha jól sejtem, a Propel is ilyesmi, és bizonyára még néhány más megoldás is áll már fejlesztés alatt.
A másik gondolatom az, hogy vajon milyen esetekben érdemes ilyen eszközökhöz fordulnunk. Ezen annak kapcsán gondolkodtam el, hogy a PEAR-t nem kedvelők táborában felvetett legfőbb probléma általában a fölöslegesen include()-olt kódmennyiség. A kérdést hetekig fontolgatva végül arra jutottam, hogy két véglet létezik, és a jó megoldást a kettő közötti megfelelő egyensúly megtalálása jelenti, ugyanúgy, ahogy például a webes alkalmazások biztonsága és az alkalmazott authentikációs technológia használatának bonyolultsága között. Ez a két végleg jelen esetben pedig a fejlesztési idő és az erőforrásigény. Magyarra fordítva azt mondanám, hogy vannak esetek, amikor gyorsan vagy struktúráltan kell fejlesztenünk, és érdemes ilyen megoldásokhoz fordulnunk, és vannak esetek, amikor Google-engine-t fejlesztünk, és célszerűbb minden külső eszköz használatát elfelejtenünk. Én azt hiszem, hogy a legtöbb esetben nem keresőt írunk, sem kereskedelmi televízió webes portálját, így nyugodtan támaszkodhatunk az ilyen eszközökre, különösen ha jól kiforrott és rendszeresen karbantartott forráskód áll mögöttük.