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

Oorspronkelijk geplaatst door Rollerscapes

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

Als je "SELECT * from Boo where id = ?" en de keys in je class mikt, dan veranderd de SQL niet heel snel plus kan je die query best genereren op basis van de condities die je aan een model geeft ofzo.

Gaat mij erom dat de data uit de database ( welke dan ook ) meteen in een object geplaatst wordt, wat voor mij toch redelijk vaak voorkomt. En hoe de query eruit ziet maakt me niet zoveel uit.
Al doe je 10 groups en unions, soms wil je dat gewoon in je object hebben
class MultiGroupUnionPowerObjectInstanceFeatureListItera tor {} :P

Die hippe query zou je trouwens kunnen afvangen met database views, dan is de ingewikkeldheid ook uit je applicatie, wat ik in die situatie denk ik fijner zou vinden.


[edit] Hij zet een spatie in Iterator woord, apart, wordwrap iets?

"Die hippe query zou je trouwens kunnen afvangen met database views, dan is de ingewikkeldheid ook uit je applicatie, wat ik in die situatie denk ik fijner zou vinden."

Doe ik ook, alleen is het 'huidige systeem' nog te verspreid omdat goed te krijgen.
Views hebben ook het voordeel dat je uit andere tabellen kan selecteren zonder dat die tabel dan SELECT rechten moet hebben (definer execute).

SELECT *?
http://www.pfz.nl/wiki/overzichtelij...-je-nodig-hebt

Oorspronkelijk geplaatst door Rollerscapes

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.

Moet je die query wel in dezelfde pagina nog een keer nodig hebben.

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.

Zodra het resultaat naar object is omgezet kan de oorspronkelijke set weg.

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).

Wat versta je precies onder Iterator?
Als je bedoelt met PDOStatement->fetch() iteratief uitlezen: dat is geen magische oplossing om geheugenproblemen te voorkomen kwam ik van de week achter.

Hij buffert dan nog steeds de gehele resultset (niet slechts 1 record) in het geheugen op het moment dat je de query uitvoert (nog voordat je fetch() aanroept).
En dat gaat met tabellen van tig GB per stuk niet echt lekker.

Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(16): failed
Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(9): failed
Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(3): failed
Oct 14 19:19:26 www3 last message repeated 155 times
Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(13): failed
Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(16): failed
Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(2): failed
Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(2): failed
Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(8): failed
Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(16): failed
Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(2): failed
Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(4): failed
Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(16): failed
Oct 14 19:19:26 www3 kernel: swap_pager_getswapspace(16): failed
Oct 14 19:19:26 www3 kernel: pid 35600 (php), uid 1001, was killed: out of swap space

Na het gebruik van de "echte" cursor functionaliteit van PostgreSQL werkte exact hetzelfde script wel goed.

Dus na "SELECT * FROM tabel" te hebben vervangen voor:

"DECLARE c CURSOR FOR SELECT * FROM tabel"
En dan met "FETCH 100 FROM c" in kleinere stapjes uitlezen.

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!

Maar goed, Doctrine staat niet synoniem voor ORM.
Andere implementaties zoals PHP AR voeren wel meteen de query uit op het moment dat je save() doet.

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.

Je moet ook niet tegen je ORM zeggen: geef me alle records, want dan maakt hij inderdaad meteen 1000 objecten aan, maar je moet om een subset vragen.
Dan maakt hij alleen objectjes voor de subset waar je om gevraagd hebt aan.

Net zoals je met PDO dus met cursors (of condities) moet werken, anders gaat het met grote sets net zo hard mis.

Als je bedoelt met PDOStatement->fetch() iteratief uitlezen: dat is geen magische oplossing om geheugenproblemen te voorkomen kwam ik van de week achter.

http://nl2.php.net/manual/en/class.pdostatement.php
http://nl.php.net/manual/en/class.iterator.php

Helaas doet PDO niet echt Iterator implementeren, dus je kan hem niet in gebruiken zoals je bij een object die Iterator implementeert zou kunnen doen Dat is wel een nadeel.

Je kan hem wel met foreach/while doorlopen.

Je moet ook niet tegen je ORM zeggen: geef me alle records, want dan maakt hij inderdaad meteen 1000 objecten aan, maar je moet om een subset vragen.

Ik doelde op LIMIT OFFSET Dus niet alle records in een tabel, maar alle resultaten van de query.

Als ik de eerste 10 record wilt verwerken, waarom zou ieder record in een object moeten zijn? Zelfs als ik ze één voor één verwerk is een object voor alleen opslag een beetje overkill.

Met ORM doe je de recors omzetten naar een objecten, alleen omdat je ze dan makkelijker kan verwerken. Maar waarom zou het systeem moeten weten hoe de interne structuur is?
Want dit word veelal vergeten, dat er Models worden gebruikt die de interne structuur naar buiten beschikbaar maken.
Met als gevolg: Je wijzigt één ding, en alles moet worden aangepast. Niet zo zeer de schuld van ORM, maar denkwijze waarop dit word toegepast.
Je werkt niet met een solide interface, maar met een 1-op-1 communicatie laag.

"DECLARE c CURSOR FOR SELECT * FROM tabel"
En dan met "FETCH 100 FROM c" in kleinere stapjes uitlezen.

Hmm die kende ik nog niet, gelukkig zijn mijn resultaten redelijk klein.
De grootste is onder de 200 records. Maar ik zal me er zeker nog in verdiepen.

Oorspronkelijk geplaatst door Rollerscapes

http://nl2.php.net/manual/en/class.pdostatement.php
http://nl.php.net/manual/en/class.iterator.php

Helaas doet PDO niet echt Iterator implementeren, dus je kan hem niet in gebruiken zoals je bij een object die Iterator implementeert zou kunnen doen Dat is wel een nadeel.

Je kan hem wel met foreach/while doorlopen.

Maar als je dus hebt:

PHP Code:

1) $db = new PDO("database login gegevens");
2) $stmt = $db->query("SELECT * FROM tabel");
3) ...doe iets met het PDOstatement object, hetzij met ->fetch(), hetzij met foreach... 


Gaat het bij regel 2 al fout.
Zodra de query wordt uitgevoerd wordt de hele uitvoer van de query in het geheugen gebuffert.

Althans dat was mijn ervaring met PDO i.c.m. PostgreSQL.
Weet niet of dit een "feature" van PDO zelf is, alleen voor de PostgreSQL PDO driver geldt, of dat de PostgreSQL client libraries dat doen.
Kan ook best zijn dat er ergens een optie is om dat uit te zetten, maar heb het dus uiteindelijk met een cursor opgelost.

Als ik de eerste 10 record wilt verwerken, waarom zou ieder record in een object moeten zijn? Zelfs als ik ze één voor één verwerk is een object voor alleen opslag een beetje overkill.

Meerendeel van de PDO gebruikers zet de records eerst 1 voor 1 om naar een associative array.
Zit niet zo gek veel verschil met een object in.
(en ja, je kan ook met column nummertjes werken).