Adatbázis absztrakciós rétegek PHP-hez
Különböző fórumokat olvasva, illetve php-vel ismerkedő emberekkel beszélgetve azt kell tapasztalnom, hogy nem ismerik elegen az adatbázis absztrakciós rétegeket. Sokan vannak, akiknek fogalmuk sincs, hogy ez mit is jelent valójában. Ha tudod, hogy miről van szó a cikkben, de nem tudod, hogy a sok lehetőség közül mikor melyiket válaszd, vagy ha egyáltalán nem tudod, miről szól ez a cikk, érdemes lesz tovább olvasnod.
Na de mi az az adatbázis absztrakciós réteg?
Nagyon leegyszerűsítve egy objektum, ami megkönnyíti az adatbázisokkal kapcsolatos munkánkat. Kicsit bővebben az absztrakciós réteg célja, hogy az azt felhasználó alkalmazás elől a funkciók tényleges megvalósítása rejtve maradjon. Ez annyit jelent, hogy alkalmazásunk csak a réteggel (objektummal) kommunikál, az adatbázis szerver felé történő kommunikációt a réteg kezeli. Hogy ez miért jó nekünk, és mennyire hatékony eszközről van szó, később látni fogjuk.
Miért használjuk adatbázis absztrakciós réteget?
A plafonból is az folyik, hogy azért használjuk, mert ezzel elérhető, hogy adatbázis szervert cseréljünk az alkalmazás alatt, egyszerűen a konfigurációs, vagy a kapcsolat paramétereit megváltoztatva. Azt már most le kell szögeznünk, hogy ez azért nem teljesen igaz, és természetesen nem ez a fő oka, ami miatt érdemes használnunk ezt a megoldást. Nem kezdem el ecsetelni, hogy ha a PHP beépített mysql_ függvényeit használjuk, később nehezebb lesz módosítani az elkészült alkalmazást. Ezen természetesen lehet javítani megfelelő, átgondolt felépítéssel, de azt azért meg kell hagyni, hogy absztrakciós réteg használta már-már rákényszerít a megfelelő struktúra kialakítására.
A másik oldalt tekintve viszont nagyon ritka az az eset (még nem találkoztam ilyennel), amikor csak a kapcsolat paramétereit megváltoztatva az alkalmazás képes lesz például MySQL helyett Oracle adatbázison futni. Ennek elsődleges fő oka, hogy alkalmazásunkat optimalizáljuk a teljesítményre. Ezt leszámítva a fenti példát tekintve Oracle-ben nincs “LIMIT” parancs. Pontosabban van arra lehetőség, hogy az eredményhalmaz csak bizonyos számú sorait kapjuk vissza, csak más módszerrel érhető el. Márpedig tudjuk, hogy minden MySQL adatbázisra épülő alkalmazásban majdnem minden lekérdezésben szerepel ez a parancs.
Mindazon által, a réteg használatával ezen eseteket kivéve az elkészült alkalmazáson történő változtatások sokkal egyszerűbb feladatokká válnak. Továbbá nem kell az alkalmazott adatbázis szervertől függően más-más funkciókat, eljárásokat megismerni, a réteg egységesített felülete a tényleges megvalósítást elrejti előlünk. Legutolsó sorban azért el kell ismerni, hogy használatukkal az élet egyszerűbbé válik. Következő cikkünkben, ezek gyakorlati alkalmazását fogjuk bemutatni, és láthatjuk, hogy mennyivel egyszerűbben és hatékonyabban lehet, alkalmazást fejleszteni a segítségükkel.
Szóval vannak előnyök, de…
mint minden másnak ennek a megoldásnak is vannak hátrányai. Azért azt mindannyian tudjuk, hogy ez a megoldás extra kód végrehajtását jelenti, de vajon milyen árat fizetünk ezért? A különböző lehetőségek más-más szolgáltatást nyújtanak, és természetesen más-más teljesítmény mellett. Alábbi táblázatban láthatjuk a teljesítménybeli összehasonlítást néhány lehetőség közül (forrás: http://phplens.com/lens/adodb/):
| Absztrakciós réteg neve | Futási idő (mp) | Lassulás (%) |
| MySQL függvények (réteg nélkül) | 1.14 | - |
| ADOdb | 1.45 | 27% |
| PEAR:DB (fetchInto fügvény) | 2.87 | 152% |
| PEAR:DB (fetchRow függvény) | 3.15 | 176% |
A teszt egy 200 soros táblából 82 sor lekérdezését jelenti, amely ötször lett egymás után lefuttatva, és az átlagos időeredmények kerültek a táblázatva. Azt jegyezzük, meg hogy 152%-al lassabb lekérdezés nem jelenti azt, hogy maga az oldal is 2.5-szer lassabban fog működni. Ez csak egy szintetikus teszt volt. Forrásanyagban viszont elkészítettek egy sokkal kézen foghatóbb eredményt is. Amelyben az mérték, hogy az oldal sebességét hogyan befolyásolja a felhasznált absztrakciós réteg sebessége. Az eredmények a következő táblázatban láthatóak, az értékek a másodpercenkénti oldalletöltést jelentik. A hardverkörnyezet illetve a teszt forráskódja a forrásoldalon megtekinthető.
| Absztrakciós réteg neve | PHP cache-el | Cache nélkül |
| MySQL függvények (réteg nélkül) | 83.53 | 81.35 |
| ADOdb | 61.19 | 21.33 |
| PEAR:DB | 52.85 | 25.26 |
Cache-nek Turck MMCache for PHP -t használtak. Ebből is látható, hogy milyen teljesítménybeli különbségek érhetőek el ehhez hasonló fordítói gyorsítótárak alkalmazásával.
Népszerű PHP adatbázis absztrakciós rétegek
Három alapvető megoldás közül választhatunk: Metabase, PEAR:DB és ADOdb. A legtöbb mai alkalmazás ezek közül valamelyiket használja. A legelterjedtebb a PEAR:DB, talán azért mert általában a PHP-vel együtt települ a futtatási környezetre. Megemlíteném a PEAR:MDB-t (és PEAR:MDB2) ami a PEAR:DB és a Metabase házasságából született, teljesítményben pedig mindkét megoldástól gyorsabb. Nézzük meg a két legelterjedtebb rétegek szolgáltatásait.
PEAR:DB
2001 óta létező adatbázis absztrakciós réteg a PEAR tárház egy csomagja, és a PHP-vel együtt tölthető le. Elterjedésének ez az egyik fő oka. Személyes véleményem, hogy elterjedését nemcsak ennek, hanem az egyszerű használhatóságának is köszönheti. Megjegyzem, hogy a PEAR-el együtt nem csak a DB csomaghoz juthatunk hozzá, hanem az MDB illetve MDB2 csomagokhoz is. A DB csomag a következő adatbázisokat támogatja:
|
|
PEAR:DB-vel kapcsolatban, további információ a http://pear.php.net/package/DB oldalon érhető el.
ADOdb
Az ADOdb egy másik említésre méltó, szintén elterjedt adatbázis absztrakciós réteg. Körülbelül 2000-től volt elérhető, elég jól támogatott, és számos népszerű webes alkalmazás használja, mint például a Mambo, phpWiki és az eGroupWare. Megjegyzem, hogy az ADOdb rendelkezik néhány extra funkcióval, ami nem megszokott egy adatbázis absztrakciós rétegtől, mint például a gyorsítótárazás. Személyes véleményem szerint az ADOdb egy megfelelően gyors, talán az egyik leggyorsabb absztrakciós réteg. Ezen felül rengeteg szolgáltatással rendelkezik. A támogatott adatbázis szerverek listája is bőséges:
|
|
Leginkább nagyobb alkalmazások fejlesztéséhez használt, hiszen külön kell telepíteni a futtatási környezetre. Ugyan létezik belőle tiszta PHP alapú kiterjesztés, de azzal mind egyet érthetünk, hogy egy C nyelven megírt, célgépre fordított PHP kiterjesztés gyorsabb működést garantál. A legtöbb webes alkalmazás nem dedikált szerveren, hanem webtárhelyeken futnak, emiatt a PEAR:DB helyzeti előnyben van. A legtöbb tárhelyszolgáltatónál a DB csomag feltelepítve található meg a szervereken. ADOdb-vel kapcsolatos további információkért látogass el a http://adodb.sourceforge.net/ weboldalra.
Összegzés
Személyes véleményem, hogy az adatbázis absztrakciós réteggel ismerkedő olvasók mindenképp a PEAR:DB-vel kezdjék az ismerkedést, de ne álljanak meg csak ennél. Alapos tanulmányozás után nézzék meg a PEAR tárház többi hasonló csomagját is (MDB és MDB2), majd az ADOdb-t. Információra kevésbé éhes olvasók az MDB és MDB2-t nyugodtan kihagyhatják.
A következő részben szó fog esni az adatbázis absztrakciós rétegek alkalmazásának módjáról, és mutatok néhány példát, amivel megkönnyíthetjük a webes alkalmazásunk fejlesztését.
RSS
20 hozzászólás, szólj hozzá Te is!
cadmagician
szép. grat.
2008. 04. 04.
diab
ez bizony jo, riszpekt!
2008. 04. 04.
DjZoNe
Szép kis írás.
Az egyetlen hibája szerintem, hogy a TurckMMCache mint olyan, már ugye nem létezik
2008. 04. 04.
Kelemen Zádor
Jó az írás. Érdemes lett volna megemlíteni a DB_DataObject-et (http://pear.php.net/package/DB_DataObject) és a FormBuildert (http://pear.php.net/package/DB_DataObject_FormBuilder). Nagyon meg tudja könnyíteni az ember munkáját.
2008. 04. 04.
slink
Egyetlen probléma a cikkel, hogy már keltezése pillanatában elavult.
Az AdoDB klassz funkcionalitást nyújt, “AdoDB a gyakorlatban” címmel be is mutattam a 2005-ös PHP konfon, az utolsó kommit viszont a CVS ágba a Trac szerint 6 évvel ezelőtt volt.
Az MBD-nek noha ravaszul nem tüntettétek fel a honlapját, az odatévedő látogatót az az üzenet fogadja, hogy “ezt a csomagot már nem fejlesztik, használd az MDB2-t helyette”.
Vgül pedig nem beszéltek a PHP5-tel érkező PDO-ról egyáltalán, amely korszerű megoldás a PHP alapú adatbázis absztrakciós problémák megoldására.
2008. 04. 04.
Zila
slink: adodb-php5-only adodb-5.04a-for-php March 25, 2008
http://sourceforge.net/projects/adodb/
2008. 04. 04.
slink
Saját magam kiigazítandó a “6 éve” butaság, az “2006 óta” akart lenni, elnézést.
@Zila: Az nem csak egy PHP5-tel kompatibilissá tett verzió? Csak azért kérdezem, mert az utóbbi időkben sehol nem olvastam új AdoDB kiadásokról. (Volt például az AdoDB Lite kezdeményezés, de ott is a projekt oldalán a legfrissebb kiadás 2007. januári keltezésű.)
2008. 04. 04.
Scr34m
ADOdb Lite nem azonos az ADOdb-vel, maga az ADOdb folyamatos fejlesztés alatt áll.
A cikkhez csak annyit tennék hozzá, hogy sokszor hasznosabb ha az ember maga készít egy hasonló rendszert mivel teljesítményben és memória használatban is kifizetődő, persze a PDO felületek PHP5 alatt további lehetőségeket nyitva nem is beszélve az új MySQLInd-rpl
2008. 04. 04.
Szaky
“This package has been superseded, but is still maintained for bugs and security fixes. Use MDB2 instead.”
Ez az üzenet van a pear::db-nél is. Szóval ha valaki most kezdni, inkább a mdb2-t kellene preferálnia - gyakorlatilag benne van a teljes DB.
2008. 04. 04.
Polonkai Gábor
DjZoNe: A Turck MMCahce legutolsó eresztése 2003-as valóban. Amint írtam, a forrásoldalról vettem a teszt eredményeket, és azt írtam, hogy ők ezt használták.
Másik dolog, hogy aki most ismerkedik az adatbázis absztrakciós rétegekkel, szerintem elég a sima DB-vel kezdenie. Az idézetben is benne van, hogy “still maintained for bugs and security fixes”. Szerintem egy kezdő ne ugorjon először a mélyvízbe. Csak szépen fokozatosan.
Másik dolog, hogy MDB2-vel voltak problémáim kb 1 éve, amikor vmi nem úgy működött ahogy annak kellett volna, az akkori legfrissebb verzióval. (Azóta biztosan javították) Ne kérdezzétek mi volt az, nem emlékszem, workaround-ot használtam.
2008. 04. 04.
PreZ
Amit még esetleg érdemes lehet vizsgálni, az a Creole db layer, ami elég friss, és teljes mértékben PHP5-ön nyugszik, bár készítettek egy legacy PHP4 verziót is, de azt nem is supportolják, mindenki saját szakállára használhatja.
2008. 04. 04.
feki
Smartyban tudnék segíteni, ha erre van igény.
Én annak idején Aurumtól fogtam fel, hogy ennek mi értelme van, szívesen adnám át a “tudás”-t másnak is. Néhány firkálmányom megtalálható a prog.hu-n is, illetve djcomplex néven egyéb fórumon is “smarty”-ra keresve.
Szerintem ez legalább olyan “ága” a php-nek, mint a db layer.
Grat. a kezdeményezéshez, tartson ki az erőtök!
2008. 04. 05.
Hodicska Gergely
Én is csodálkozom, hogy 2008-ban nem esik szó a PDO-ról. Minimálisan jelent plusz memória foglálást a mysql és a mysqli függvényekhez képest, és sebességben pedig abszolút nem marad el mögöttük. A Doctrine is PDO-t használ.
@PreZ: a Creole azért már elég régi darab, egyike volt az első komolyabb PHP5-ös fejlesztéseknek. Ráadásul elég lassú is, nem véletlen, hogy a Propel is áttért a PDO a Propelről.
@Scr34m: Ne keverd, a mysqlnd az a libmysql kiváltására szolgál, nem egy új függvénycsoport, vagy ilyesmi. Ugyanúgy a mysqli függvényeket, vagy a PDO-t fogjátok használni.
Üdv,
Felhő
u.i.: Pontosan nem tiszta, hogy kinek szánjátok ezt a blogot, vagy mi a célotok vele, de szerintem komolyabb (”igazi”) tartalmakkal lenne érdemes kijönni, tapasztalaton alapuló dolgokkal. Ez a tartalom kb. 3-4 éve lehetett érdekes (kb. a linkelt dolgok is ilyesmi idősek, vagy még régebbiek), ma már szerintem lényegesen előrébb jár a szakma.
2008. 04. 05.
Scr34m
@Felhő: nem keverem csak azis egy új lehetőség lesz ami miatt érdemes lesz váltani, http://ilia.ws/files/phpquebec_php53.pdf
2008. 04. 05.
Hodicska Gergely
@Scr34m: de a DB layerek viszonylatában nincs váltás, alapvetően nem is fogod tudni, hogy libmysql, vagy mysqlndt használsz (illetve lesz néhány plusz függvény), ezért nem értem a váltás szót. 5.3-at elég jól kiveséztem annó:
http://blog.felho.hu/what-is-new-in-php-53-part-4-__callstatic-openid-support-userini-xslt-profiling-and-more.html
http://blog.felho.hu/what-is-new-in-php-53-part-3-mysqlnd.html
http://blog.felho.hu/what-is-new-in-php-53-part-2-late-static-binding.html
http://blog.felho.hu/whats-new-in-php-53-part-1-namespaces.html
Üdv,
Felhő
2008. 04. 05.
Gyurkó Zoltán
Egyetértek Felhővel és slinkkel kicsit elavult a cikk. Manapság bennem leginkább úgy merül fel a kérdés, hogy miért használna valaki mást a PDO helyett.. erről sokkal szívesebben olvasnék valamit pro és kontra.
2008. 04. 05.
Scr34m
@Felhő: valóban igazad van át siklottam, hogy ez cserélni fogja libmysql-t pedig Ila prezentációjában is egyértelmű illetve a tiedben is sorry
@Gyurkó Zoltán: sajnos van ahol még ennek a régi módszernek is mennie kell mert még PHP 4 fut a szerveren, pl nekem is folyamatosan dolgoznom kell PHP 4 és PHP 5 futtató szerverekkel
2008. 04. 05.
Polonkai Gábor
http://hu.php.net/pdo
PDO manual-ból:
“PDO provides a data-access abstraction layer, which means that, regardless of which database you’re using, you use the same functions to issue queries and fetch data. PDO does not provide a database abstraction; it doesn’t rewrite SQL or emulate missing features. You should use a full-blown abstraction layer if you need that facility.”
A bejegyzés 2. részét az adodb és hasonlók felhasználásának módjáról akartuk írni, de a hozzászólásaitok teljesen más irányba vittek el. (Azt hittem, kevésbé tapasztalt és informálódott, gyakorlatilag kezdő olvasók lesznek többségben.) Felmerült, (16. hozzászólás Gyurkó Zoltán) hogy jó lenne összefoglalni pro és kontra érveket az egyes megoldások közül. Azt hogy kinek mi a pro és kontra teljesen különböző lehet, ebben megegyezhetünk. Mindazonáltal egy olyan írást sem találtam, ahol a különböző megoldásokkal elérhető funkciók és szolgáltatások össze lennének hasonlítva. Jelenleg egy “nagy táblázaton” dolgozom, amiben a PEAR:MDB2, ADOdb és PDO rétegek lesznek összehasonlítva.
Ki fogom bővíteni a kommentezést egy “reply-to” funkcióval.
2008. 04. 05.
Drawain
Nem tudom volt e már róla szó, de nem akartok valamit kezdeni a designal?
A hozzászólásokat olvasni gyakorlatilag kínszenvedés, sose tudom hol van a vége, vagy ki írta…
2008. 04. 06.
Hozzászólás írása: “Adatbázis absztrakciós rétegek PHP-hez”