Kezdem Ádám-Évától. SQL92. Ez már sejtetni engedi, hogy valamiféle SQL különbségekről van szó. Hát igen. Mivel keretrendszert készítek, így cél az, hogy több adatbázis típust ismerjen. Egyelőre a MySQL és a PostgreSQL a kitűzött cél. Jómagam a rugalmas rendszereket és nyelveket szeretem, ezért kezdtem el a PHP-vel is foglalkozni. A kezdetekkor az ingyenesen hozzáférhető adatbázisok közül az M betűs előbb szerepelt az ábécében, mint a P betűs. Igy a MySQL lett az amelyikkel éveken át dolgoztam. Sok hátrányát, mely területeken a PostgreSQL előnyt élvez, azokon a programokon amin dolgoztam nem éreztem. Ám mindkettő fejlődött tovább az évek alatt, és hamár a Zend Framework kezeli őket, hát én is léptem. A PostgreSQL nagyon megtetszett, és még koránt sem használtam ki a lehetőségeit. De sajnos a két rendszer közötti külőnbségek sokszor bosszantanak. Ugyan a Zend Framework rendszer szinten kezeli mindkettőt, ha a rendszer select építőjét használom, ám az nem mindig elég.
CASE mezo_1 WHEN 1 THEN mezo_string WHEN 2 THEN mezo_integer WHEN 3 THEN mezo_date END AS mezo_ertek
A fenti példában a PostgreSQL előre meghatározza az eredménymező típusát. Mivel itt különböző típusúak lehetnek, ezért reklamál. A MySQL nagyvonalú eleganciával visszaadja amit várok. A PostgreSQL esetében kell egy kis trükk. Ha hozzáfűzök egy kis szöveget, mondjuk a semmit, akkor már minden mező szöveges.
CASE mezo_1 WHEN 1 THEN mezo_string || '' WHEN 2 THEN mezo_integer || '' WHEN 3 THEN mezo_date || '' END AS mezo_ertek
Így már jó, csak a MySQL nem így fűz össze. SQL92 nesze-neked.
CASE mezo_1 WHEN 1 THEN mezo_string %pgC% WHEN 2 THEN mezo_integer %pgC% WHEN 3 THEN mezo_date %pgC% END AS mezo_ertek
A %pgC% sablon érték már SQL típustól függően változtatható, csak emiatt kellett írni egy sablon értelmezőt is. Grrr...
Utolsó kommentek