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