[php/sql] database abstractie laag hoe en wat

[tombo_inc]

beste mensen,

ik ben bezig met een grote php applicatie waarvan ik wil dat deze (redelijk) database onafhankelijk kan werken. nu heb ik gehoort dat dit mogelijk is dmv van een DAL of database abstractie laag. ik heb veel gezocht naar het hoe en wat op google en hier op het forum, maar ik kan nog niet echt alles op een rijtje zetten. daarom heb ik nog een aantal vragen hierover.

- Wat is een database abstractie laag nou precies?
voor zover ik te weten ben gekomen is het een laag tussen je code en je werkelijke queries.
je maakt dus voor iedere database die je wil ondersteunen een soort driver met daarin de queries voor de betreffende database. en je abstraheerd dan de queries in je code zodat die hetzelfde zijn, de database laag vertaald die dan dus naar de juiste query. is mijn visie van zo'n database abstractie laag juist of zit ik er ver naast.

- hoe kun je het beste zo'n database abstractie laag maken?
kun je het beste voor iedere DB een los bestand aanmaken met daarin de database class. en dan vervolgens aan de hand van het ingestelde dbtype de juiste "driver" file includen? of moet je alles in één bestand proppen. of is er een betere methode?

ik zou graag jullie visie hierover willen horen.

Met vriendelijke groet,
Tom

[dingstje]

Wat ik persoonlijk doe is werken met een connectionstring en een DBFactory. Ik geef bvb de connectionstring (die in de praktijk een Array is zodat ik niet bij elke request moet gaan exploden) mee:

PHP:

$connectionString = Array(
'type' => 'mysql', 
'user' => 'foo', 
'password' => 'bar', 
'database' => 'foobar'
);

Dan geef ik dat door aan mijn DB factory die checkt welk type het is en de juiste file included (MySQLDB bijvoorbeeld) en de connectionstring dan weer doorgeeft aan de static Create function van MySQLDB. Deze geeft een instance van MySQLDB terug. Deze MySQLDB implements een interface zodat ik alles dat ik terug krijg van mijn DBFactory kan gebruiken met recordSet(), exec() en insert() (insert() geeft het ID van de ingevoegde row terug).

Edit: Het is hiervoor dan wel nodig om prepared statements (of eventueel prepared statements/triggers zelf implementeren, zodat je zeker bent dat elke geïmplementeerde database ermee overweg kan) te gebruiken, anders heb je nog altijd het probleem dat je SQL mogelijk niet werkt op elke database.

[ Voor 23% gewijzigd door dingstje op 03-06-2005 20:54 ]

[djluc]

Je kan met een beetje object georienteerd werken iets moois maken. Je krijgt dan een standaard class welke je uit kan breiden per database. Je zou eens moeten kijken naar wat andere database classes, daar zie je veel goede voorbeelden. In principe komt het er op neer dat je geen SQL meer schrijf maar dat je methoden (functies in je DB class) aanroept met argumenten. Deze maakt dan de juiste SQL.

[tombo_inc]

juist, dit komt idd aardig overeen met hetgeen ik in gedachten had. je maakt inderdaad zelf geen sql meer maar laat dit doen door functies van de desbetreffende DBclass. je zorgt dat alle aanroepen voor eenzelfde bewerking het zelfde zijn, en laat die dan uitvoeren door de DBclass zodat het werkt op verschillende databases. dat is dus het princiepe van een database abstractie laag als ik het dus goed heb?

[DPLuS]

Mijn favoriet voor PHP:

http://pear.php.net/package/DB