Onderwerp: Welke database abstraction layer (DBAL) raden jullie aan? (DB, MDB2, PDO, AdoDB?)

Goede avond allemaal.


In het kader van OOP programmeren wil ik op een goede wijze een database aanspreken zonder afhankelijk te zijn van type database.


Als ik het correct heb kom ik dan uit op Database abstraction layer. Na wat rondneuzen kom ik bij verschillende uit. DB.php van PEAR word veel gebruikt, maar is ook weer verouderd. De opvolger hiervan is weer MDB2 (nog steeds in beta? toch word DB nog veel gebruikt?) PDO van PHP en AdoDB zijn er ook nog....


Kort gezegd: Ik zie door de bomen het bos niet meer.
De vragen aan jullie: Welke boom kan ik volgens jullie het beste gaan beklimmen?


Ohja, het moet kunnen draaien op een DirectAdmin omgeving (evt met extra dingen geïnstalleerd). Een uitgebreide Zend framework/omgeving is dus (nog..) geen optie...


Wat vinden jullie trouwens hiervan? http://phplens.com/lens/adodb/

Wat is het probleem met het Zend Framework? Dat is niets meer dan PHP.

Oorspronkelijk geplaatst door MortyDot

Wat vinden jullie trouwens hiervan? http://phplens.com/lens/adodb/

Waardeloos, als ik naar de versie nummers kijk is deze opsomming al van enige tijd geleden en het totaal beeld kan compleet veranderd zijn. Of bedoelde je dat niet ?

@Mikey,
Ja dat is mijn indruk dus ook. De beschikbare DBAL opties lijken me voor mijn gevoel allemaal verouderd. Vele zijn de laatste updates op zijn laatst 2jaar geleden toegepast.

Vandaar mijn vraag wat jullie ervaring is. Of gebruiken jullie geen DBAL? Ik ben vanuit java niet anders gewend...

@Wido, ik bedoelde software zoals zend server/platform, etc., niet zend core

Voor het simpele SQL werk: PDO. Doet wat het moet doen, en zit standaard bij PHP.

Met Zend framework ook wel eens gewerkt, maar vindt het irritant dat deze niet modulair is.
Vind maar een paar onderdelen nuttig, en wil niet de rest van de 2000 classes met mijn projectjes meeleveren.


Mocht SQL niet je ding zijn, en je de database alleen als opslagvat nodig hebben, dan zou je ook nog naar de verschillende ORM implementaties kunnen kijken: http://en.wikipedia.org/wiki/Active_record_pattern#PHP

Oorspronkelijk geplaatst door maxnet

Met Zend framework ook wel eens gewerkt, maar vindt het irritant dat deze niet modulair is.
Vind maar een paar onderdelen nuttig, en wil niet de rest van de 2000 classes met mijn projectjes meeleveren.

Zend framework is toch wel modulair, je kan je applicaties mooi opsplitsen per module. Wij gebruiken het ook al een heel tijdje, in combinatie met Propel als ORM. Voor mij is dat een mooie combinatie.

Peter

Oorspronkelijk geplaatst door fastrep

Zend framework is toch wel modulair, je kan je applicaties mooi opsplitsen per module.

Je kan je EIGEN applicatie zo modulair maken als je wilt, maar het framework zelf is dat beslist niet.
Ze bieden maar 2 smaken aan:

- Zend Framework Minimal: 2000+ PHP bestandjes
- Zend Framework Full: nog meer.


Ik mis een optie om bijvoorbeeld alleen de Zend_Db classes te downloaden i.p.v. alles of niets.
(handmatig de "Zend_Db" bestandjes er tussen uit halen is niet eenvoudig, omdat die dependencies op andere classes hebben, en deze niet gedocumenteerd zijn.).

Je kan inderdaad wel bepaalde componenten gebruiken van ZF alleen moet je daarvoor het hele framework importeren (30MB?).

Zelf gebruik ik PDO. Voor ORM gebruik ik Doctrine (gebruikt ook PDO als DBL).

Misschien dat je jezelf moet vragen waar je het voor gaat gebruiken en waar het aan moet voldoen en daar je keuze op baseren?

@Costeijn,

Ja hier was mijn oog ook al op gevallen. Een ORM zoals Cake oid.
Enkel zocht ik een DBAL voor een kleiner iets zonder gelijk een ORM (zoals Cake-PHP) nodig te hebben.

Voor grotere software stukken viel mijn oog al op CakePHP.

Ik blijf maar aan het oriënteren en handleidingen door lezen en proberen...
Ik was echter nieuwsgierig naar jullie ervaring zonder gelijk in iedere top van elke bomen te hoeven proberen

Toevoeging (beetje off-topic):
Lijstje met ORM's: http://en.wikipedia.org/wiki/List_of...g_software#PHP

"Mocht SQL niet je ding zijn, en je de database alleen als opslagvat nodig hebben, dan zou je ook nog naar de verschillende ORM implementaties kunnen kijken: http://en.wikipedia.org/wiki/Active_record_pattern#PHP "

ORM, een oplossing voor een niet bestaand probleem.
Bereid je voor op een flamewar

ORM Is zonder meer één van de domste oplossing die ooit heeft bestaan!
Je gaat gegevens uit een database 1-op-1 porten naar objecten, waardoor je de database degradeert tot kaartenbak/kladblok.

Met de database kan je gegevens groeperen (GROUP), samenvoegen (UNION), sorteren en noem maar op.
Op het moment dat je ORM gaat toepassen (in de simpelste vorm) verlies je al die flexibiteit en moet je alles op applicatie niveau weer op aan elkaar gaan plakken. En ga dus dubbel dingen doen.

Sommige ORM systemen zijn gelukkig iets slimmer dan dat en bieden ook een SQL gelijkende versie.
Alleen zijn deze nooit zo goed geoptimaliseerd als de SQL zelf.


En dan het werken met gegevens, alles wat word opgehaald word naar een object omgezet met als enige doel het opslaan in een object (Wat is er mis met een Array?), en als je 1000 records hebt (omdat je die wil gaan exporten naar een CSV/XML file bijvoorbeeld) heb je dus 1000 objecten !! Dit gaat geheid zorgen voor onvoldoende geheugen.

En dan het invoeren, elk record moet naar een object. En ik weet van iemand die zelf ORM gebruikt, dat dit uitloopt veel frustratie. Je komt namelijk al snel geheugen tekort.

Om dingen toch als object op te kunnen halen zonder alle problemen kan je het Iterator pattern gebruiken. Deze werkt veel sneller en beter.


En dan als laatste, iets waar Doctrine veel reclame mee maakt.
Je voert een query uit, en verwacht dat het goed is. Wat doet Doctrine, hij slaat de query op en en gaat hem later uitvoeren.

Op het moment dat iets fout gaat ben je al voorbij de controle en heb je een groot probleem (wie verzint dit??)

En dan maken ze er reclame mee omdat het 'sneller' zou zijn, wat is er in godsnaam sneller aan om query's direct achter elkaar uit te voeren i.p.v van per keer.

En wat te denken van transacties?
Je start een transactie omdat je de de zekerheid moet hebben dat het bestaat of consistent is.

Stel je maakt een nieuwe webhosting account aan.
Je start een database transactie, voert de gegevens in, en maakt de homemap aan. Als dat laatste fout gaat doe je een rolback. Omdat meneertje alles achteraf doet weet je dus nooit zeker of dit is goed gegaan..


Minpunten van ORM zijn.

• Vermindering van snelheid
• Onnodig veel geheugen gebruik
• Je hebt veel minder flexibiliteit dan met SQL, welke is geoptimaliseerd voor de database
• Slechte foutafhandeling
• Programmeren naar implementatie, en niet naar een interface

http://maryniuk.blogspot.com/2009/09...even-more.html
http://dayhacker.blogspot.com/2009/0...-hell-lot.html
http://softwareobjects.net/technolog...-suck-or-what/
http://kore-nordmann.de/blog/why_act...ord_sucks.html
http://people.planetpostgresql.org/d...from-ORMs.html

De manier waarmee de meeste garantie hebt is, hoe het vervelend ook klinkt voor elk database systeem eigen DataMapper maken. En daarmee missende functionaliteit van een database aanvullen.

Als je zeker weet dat je maar één database type gaat gebruiken, kan je gewoon de queries in de code zelf houden.
Al dan niet gebruikmakende van een Class voor foutafhandeling.


Als je het wilt gebruiken, je bent gewaarschuwd

Programmeren naar implementatie, en niet naar een interface?

ORM zorgt juist voor het abstraheren van je datalaag.

e hebt veel minder flexibiliteit dan met SQL, welke is geoptimaliseerd voor de database

Je hebt alles als een object? Waarom is dit minder flexibel?

Oorspronkelijk geplaatst door Rollerscapes

En dan het werken met gegevens, alles wat word opgehaald word naar een object omgezet met als enige doel het opslaan in een object (Wat is er mis met een Array?), en als je 1000 records hebt (omdat je die wil gaan exporten naar een CSV/XML file bijvoorbeeld) heb je dus 1000 objecten !! Dit gaat geheid zorgen voor onvoldoende geheugen.

Houd er rekening mee dat hetzelfde geheugen probleem zich voor kan doen als je gewoon met SQL "SELECT * FROM tabel" doet.
Bij de meeste database drivers buffert PHP namenlijk standaard de hele resultset in het geheugen.
Je moet dan ook met cursors te werken (als je dbms dat ondersteund) of condities opgeven om dat te voorkomen.

Dat is met een ORM niet anders. Je moet hem nooit vragen om de hele inhoud van een grote tabel in 1x te geven, maar om een subset.

En dan het invoeren, elk record moet naar een object. En ik weet van iemand die zelf ORM gebruikt, dat dit uitloopt veel frustratie. Je komt namelijk al snel geheugen tekort.

Begrijp het probleem niet helemaal.
Of ik nu met PDO doe:

PHP Code:

$stmt = $db->prepare( "INSERT INTO gebruikertjes(naam,hash,emailadres) VALUES (?,?,?)" );
$stmt->execute( array($naam, $passhash, $email) ); 


Of met een ORM:

PHP Code:

$g = new Gebruikertje();
$g->naam = $naam;
$g->hash = $passhash;
$g->emailadres = $email;
$g->save(); 


In beide gevallen is er tijdelijk geheugen nodig.
In het eerste geval voor een array met alle gegevens, en in het tweede geval voor een object met dezelfde gegevens.
Zodra $g out-of-scope gaat wordt het object opgeruimt, en is het geheugen weer vrij.


Slaat je kennis documenten van 100 MB in zijn database op ofzo?


Ben het overigens wel met je eens dat SQL altijd flexibeler is. Maar de vraag is of dat bij de meeste webapplicaties wel nodig hebt.
Vaak wordt de database slechts als kaartenbak gebruikt, en niet om afgeleide gegevens te genereren, of massa-bewerkingen te doen.

@Rollerscapes

Beetje ongenuanceerd verhaal, je noemt enkel nadelen. Zeggen de termen onderhoudbaarheid en developer productiviteit jou iets om maar eens iets te noemen?

Ondanks dat ORM hier de grond in word geramt door Rollerscapes, gebruik ik het zelf voor kleinere projecten. Je hebt niet altijd die mega flexibiliteit nodig van SQL, en een lompe "kaartenbak" kan zeker gewoon voldoen voor de simpelere dingen.
In mijn vorige baan veelvoudig gebruikt gemaakt van PDO, persoonlijk mijn eigen favoriet, het werkt gemakkelijk en doet in mijn inziens wat het moet doen.
Bij mijn huidige baan gebruiken ze een eigen geschreven DAL, iets waar je ook nog voor zou kunnen kiezen ( wel veel werk terwijl er alternatieven zijn ).

O ja, wat ik zelf wel handig vond is dat PDO direct objecten uit je records kan trekken ( wat rollerscapes dus afkraakt ), heb ik zelf erg handig gevonden in veel situaties.
PDO::query ( string $statement , int $PDO::FETCH_CLASS , string $classname , array $ctorargs )

Onderhoudbaarheid, zeker
Daarom werk ik ook met MVC principe.

Daarnaast maak ik veel gebruik van User defined functions en Views, waardoor het aantal plaatsen waar je dingen moet aanpassen kleiner word.

"developer productiviteit"
Met SQL weet ik wat ik doet, met ORM moet ik maar gissen of hij er iets zinnigs van maakt, je abstraheert de invoer tot op het uiterste. Daarom krijg je vrijwel nooit een SQL query die geoptimaliseerd is voor het database systeem.

Iets wat in MySQL heel snel is, kan een PostgreSQL systeem doen zweten, omdat hij niet goed weet al je precies bedoeld en dus verkeerde beslissing neemt.

Begrijp het probleem niet helemaal.
Of ik nu met PDO doe:

PHP-code:

PHP Code:

$stmt = $db->prepare( "INSERT INTO gebruikertjes(naam,hash,emailadres) VALUES (?,?,?)" );
$stmt->execute( array($naam, $passhash, $email) ); 


Of met een ORM:

PHP-code:

PHP Code:

$g = new Gebruikertje();
$g->naam = $naam;
$g->hash = $passhash;
$g->emailadres = $email;
$g->save(); 


Kijk is heel goed naar de interne werking
Bij het PDO voorbeeld doe je de Query voorbereiden, zodat hij hem elke keer kan hergebruiken zonder eerst te moeten controleren of de syntax wel goed is en zo.

Met de ORM, moet hij elke keer de query controleren.

O ja, wat ik zelf wel handig vond is dat PDO direct objecten uit je records kan trekken ( wat rollerscapes dus afkraakt ), heb ik zelf erg handig gevonden in veel situaties.

Die kende ik nog niet, maar dan zit je wel met het probleem dat als je SELECT query veranderd je de hele Class moet aanpassen. Je zit dan eigenlijk vast aan een solide implementatie ipv een interface waar je dingen expliciet ophaalt.
En zeggen dat die query nooit zal veranderen is de godenverzoeken

Daar komt bij dat je nu een Class gaat gebruiken voor het opslaan van gegevens, en de verwerking. Maar betekend dit dat je de Query op meerdere plekken gebruikt?! In de Model gegevens ophalen, ze daar verwerken en via een solide getter naar buiten beschikbaar maken bied dan veel meer zekerheid voor de toekomst.

Houd er rekening mee dat hetzelfde geheugen probleem zich voor kan doen als je gewoon met SQL "SELECT * FROM tabel" doet.
Bij de meeste database drivers buffert PHP namenlijk standaard de hele resultset in het geheugen.
Je moet dan ook met cursors te werken (als je dbms dat ondersteund) of condities opgeven om dat te voorkomen.

Dat is met een ORM niet anders. Je moet hem nooit vragen om de hele inhoud van een grote tabel in 1x te geven, maar om een subset.

Ja en nee, als je in PHP een query uitvoert die resultaten teruggeeft.
Worden die in het geheugen van PHP bewaard, maar op het moment dat je ze gaat gebruiken als object/array dan moet hij ze omgaan zetten.
En dan krijg je een dubbele set.

De informatie rij per rij uitlezen via een Iterator, welke ook word ondersteund door PDO is dan efficiënter. Voor het PHP uitvoer gedeelte doe je dan enkel per record(set) de gegevens uitlezen en verwerken.
Dan werk je echt met een cursor (bij PDO dan).

ORM zorgt juist voor het abstraheren van je datalaag.

Ja maar, tegen welke prijs. Een Datamapper is veel flexibeler en kan eventueel ook worden gebruikt voor niet DB-opslag.

Je hebt alles als een object? Waarom is dit minder flexibel?

Ik doel hier met name op ActiveRecord.

Probeer dit maar is in ActiveRecord voor elkaar te krijgen.

Code:

SELECT
	SUM(log_entries.bytes_sent) AS traffic_use
	,g.num AS traffic_day
FROM
	generate_series(1, days_list(date_part('month'::text, NOW())::integer, date_part('year'::text, NOW())::integer)) AS g(num)
LEFT JOIN
	log_entries
ON
	date_part('day'::text,  request_time) = g.num
AND
	date_part('year'::text, log_entries.request_time) = date_part('year'::text, NOW())
AND
	date_part('month'::text, log_entries.request_time) = date_part('year'::text, NOW())
AND
		account_id = :account
GROUP BY
	traffic_day
	,date_part('month'::text, log_entries.request_time)
ORDER BY
	traffic_day ASC

Oké, toegegeven dit is iets wat MySQL (nog) niet ondersteund dus dit abstraheren naar DBAL zou onmogelijk zijn.

Voor PostgreSQL, en andere die dit wel ondersteunen (al dan niet via een omweg) kan je gewoon een normale Datamapper maken, en voor MySQL, SQLite doe je de missen functionaliteit aanvullen in PHP.

Op deze manier maak een Addapter interface die gericht is op de database zelf, en ga je niet een een zeer handige functionaliteit dumpen omdat er twee database systemen zijn die dit niet ondersteunen.


"Ben het overigens wel met je eens dat SQL altijd flexibeler is. Maar de vraag is of dat bij de meeste webapplicaties wel nodig hebt.
Vaak wordt de database slechts als kaartenbak gebruikt, en niet om afgeleide gegevens te genereren, of massa-bewerkingen te doen. "

En de administratie dan?
In mijn database ontwerp zijn tal van relaties, en controles (FK, triggers) omdat allemaal consistent te houden.

Ondanks dat ORM hier de grond in word geramt door Rollerscapes, gebruik ik het zelf voor kleinere projecten. Je hebt niet altijd die mega flexibiliteit nodig van SQL, en een lompe "kaartenbak" kan zeker gewoon voldoen voor de simpelere dingen.

Als het zo simpel is, waarom moet je dan ORM gebruiken
De meeste queries zijn uitwisselbaar per database, met enkele kleine verschillen. Welke je nog op zou kunnen lossen door per database-type een bestand te maken waar alle queries instaan per naam.
Nu gebruik je een heel groot log iets, voor iets heel kleins.


ORM Is te geheugen intensief voor grote projecten, en voor kleine is het te groot en log.

Slaat je kennis documenten van 100 MB in zijn database op ofzo?

1000 records invoeren, is niks
Ik heb een tabel daar staan minstens 1.000.000 records in.

En soms moet je grote hoeveelheden invoeren/exporteren, dus doe je dat stukje voor stukje.
Wat doe Doctrine? Buffert elke invoer, en voert die later later uit! Met als resultaat dat je een bestand dat deel voor deel word uitgelezen alsnog helemaal in het geheugen zet.

Exporteren het zelfde verhaal, hij gaat eerst een grote hoeveelheid objecten maken die je vervolgens kan doorlopen (1000 records = 1000 objecten).
En omdat hij ze eerst moet aanmaken, heb je niet dat voor elke iteratie een object word aangemaakt en weer verwijderd Je hebt echt 1000 objecten en groot probleem.
Alleen als je zelf een ORM systeem maakt dat slimmer is dan dit ben je een probleem armer. Maar dan nog heb je niet de flexibiliteit van plain SQL met een Datamapper.


Op PFZ.NL zijn nog wat topics die dieper op deze discussie ingaan.
http://www.pfz.nl/archief/1200579-re...ao-wat-is-het/
http://www.pfz.nl/archief/815949-re-...stence-layers/
http://www.pfz.nl/archief/1271912-doctrine-20/Hier/
http://www.pfz.nl/archief/1181644-al...en-in-1-query/
http://www.pfz.nl/archief/1181763-re...atabase-typen/
http://www.pfz.nl/archief/1237347-re-bussinesslogica/

Uiteraard is de keuze aan je zelf, maar ik waarschuw je alleen maar dat het ook minder rooskleurig is dan het allemaal lijkt.

Dat het nu goed werkt, wil niet zeggen dat het in de toekomst ook nog zo lekker werkt.