ugrás a tartalomhoz

SQL::Translator, az SQL mindenes

Bártházi András · 2005. Jan. 4. (K), 16.28
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 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)
Az első öt a különböző SQL dialektusokról szól. A DBI-al kezdődő parser-ek közvetlenül az adatbázisból képesek azok szerkezetét lekérdezni, majd a többi parser különböző formátumok szerkezetét képes felderíteni. Elég kellemes választék, azonban a producer-ek listája ennél is bővebb: akár dokumentáció készítésére is használhatjuk ezt az egyszerű modult:
  • 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
Az első pár elem a listában különböző SQL dialektusokat tartalmazó szövegfájlok létrehozását jelenti, utána HTML és POD dokumentációk, Perl kódgenerátor, grafikus diagrammok és már megoldások következnek.

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!
 
1

vélemény

Mocsnik Norbert · 2005. Jan. 5. (Sze), 00.05
Nagyon izgalmas. Két gondolatom merült fel a fentiekkel kapcsolatban.

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.