[PHP]PHP DataAdapter

[DDemolition]

Ik zit al een tijdje met idee om een data adapter te bouwen voor php.
Ik wil een klasse bouwen die die connectie regelt met de database, zodat ik redelijk onafhankelijk ben. Een beetje het .NET idee zeg maar
Als ik bv. kan verbinden met mysql en postgres ben ik al een heel eind. Mocht ik nog naar meer databases willen verbinden kan ik dit bij bouwen.
De functies die ik écht ga gebruiken (en dat zullen er niet zo heel veel zijn) moet ik immers dan toch direct schrijven in m'n klasse. Kleine kans dat het in de ene database wel of niet werkt. Het enige waar ik tegenaan loop is wat sql dialect, zoals LIMIT in mysql.

Uiteindelijk krijg ik dan zoiets als:

PHP:

<?
$rs = $da->fQuery("SELECT * FROM tbltest");
$count = $da->fCount($rs);

//$rs loopen op de een of andere manier
?>

Dit stukje is als voorbeeldje, maar het gaat om het idee. Ik wil dus mysql_num_rows op die manier afvangen en in dit in de klasse zelf wegschrijven.

Zou deze methode te ver gezocht zijn, of kan ik beter voor een tussenslag gaan, zoals XML of iets PEAR's achtigs? Of nog beter...zijn hier al schitterende oplossingen voor?
Er is niet zo heel veel over te vinden. Ik weet wel dat bv. mambo, joomla ed. een heleboel kunnen op dat gebied wat betreft het gebruik ervan.

[ Voor 14% gewijzigd door DDemolition op 06-07-2006 17:17 ]

[Verwijderd]

Misschien moet je hier eens naar kijken : http://nl2.php.net/pdo.

[DDemolition]

Verwijderd schreef op donderdag 06 juli 2006 @ 17:13:
Misschien moet je hier eens naar kijken : http://nl2.php.net/pdo.

Dat ziet er al redelijk gaaf uit! Ik zal er vanavond eens mee gaan spelen. Ik weet niet of dit bij veel hosting bedrijven meegecompileerd wordt? Ik beheer m'n servers btw wel zelf, maar hoe onafhankelijker des te beter..

[moozzuzz]

PHPNuke heeft/had ook zo'n layer.php file die abstractie maakt voor verschillende databases. Op een bepaald moment kon ik geen enkele mysql_xxxx functie meer (ambetant in andermans projectjes zonder zo'n layer ;^)

Ik spreek wel over de tijd 99-01

[Cyphax]

Als je echt onafhankelijk wil blijven kun je het beste zorgen dat PHP de enige vereiste van de webserver is, met meegecompileerde modules voor de databaseserver die je wil gebruiken.

Ik ook een keer zo'n stukje framework geschreven voor databaseverbindingen (onder andere) en 'm zo opgedeeld dat je een soort van driver kreeg voor een bepaalde DB (MySQL, PostGreSQL, etc) en een generieke class die je include waar je mee werkt. Voordeel is dat je veelvoorkomende logica in je class kunt frotten. Dan komt je code bijvoorbeeld niet vol te staan met loops door een recordset maar doe je dat in je class ergens en laat je die een array returnen ofzo.
Nouja, iig is het idee niet nieuw, maar als je het leuk vindt om te maken en je wilt zorgen dat je geen extra dependencies creeert zou ik dat gaan doen eigenlijk.

[aex351]

ik gebruik de adapter pattern ook op regelmatige basis. Mits je het goed toepast heeft het een super werking. Is als het ware aliasen.

[ReverendBizarre]

Kijk ook eens naar AdoDB. Dit is een bestaande library die al doet wat je hier van plan bent te maken.

http://adodb.sourceforge.net/

[Edit: en hoeft ook niet meegecompileerd te worden in PHP of wat dan ook, dus je bent volledig onafhankelijk van de server wat betreft PHP instellingen. Je zet die bestandjes neer, includen, en klaar.]

[ Voor 45% gewijzigd door ReverendBizarre op 06-07-2006 18:35 ]

[Michali]

Als je echt onafhankelijk wilt werken, dan kun je het beste alles abstraheren. Queries bouw je dan op met behulp van objecten, en de SQL code laat je daardoor dan genereren. Afhankelijk van je gebruikte DB app. wordt dan de juiste SQL code gegenereert en uitgevoerd. Zo werk ik, en dat gaat wel goed. Je kunt natuurlijk niet alles dekken, maar voor 80% van de gevallen kun je dit wel zo goed gebruiken, en dat is al meer dan de moeite waard.

[Jerry]

Een kwestie van een abstracte klasse maken voor een generieke database en als je een speciaal type database hebt gewoon extenden? Ik zie het probleem niet .
Moet je wel beschikken over PHP5...

Voorbeeldje:

PHP:

abstract class Database
{
    // Const vars
    const DB_PERSISTENT     = true;
    const DB_NON_PERSISTENT = false;

    // Private vars
    private $name = "";
    private $host = "";
    private $link = 0;

    // Constructor
    private function __construct( $name, $host )
    {
        $this->name = $name;
        $this->host = $host;
        $this->link = 0;
    }
        
    // Abstract functions
    abstract function connect( $username, $password, $type = Database::DB_NON_PERSISTENT );
    abstract function query( $sql );
    abstract function getSqlError( );
}

En dan voor Mysql:

PHP:

require("Database.class.php");

class MysqlDB extends Database
{   
    public function __construct( $name = null, $host = null )
    {
        parent::__construct( $name, $host );
    }
        
    public function connect( $username, $password, $type = Database::DB_NON_PERSISTENT )
    {
        mysql_connect(...); // You get the point ;)
    }

    public function query( $sql )
    {
        return mysql_query( $sql, $this->getLink() );
    }
        
    public function getSqlError( )
    {
        return mysql_error( $this->getLink();
    }
}

Zelf maak ik van de resultset die je terugkrijgt van mysql_query ook een object die ik ook weer abstraheer van een generieke resultset.
Die regelt alle getNumRows(), getCurrentRow(), getRow(), etc .

[ Voor 13% gewijzigd door Jerry op 06-07-2006 18:46 ]

[DDemolition]

Zoiets was ook de bedoeling ja. Als ik 1x een kleine kopieslag doe hoeft zelf bij gebruik van mysql de PostgreSQL classes niet te bestaan (tijdens het configureren voeg ik gewoon de goede classe toe).
Ideen zijn er op zich genoeg, ik ziet alleen nog te twijfelen tussen bestaand of zelfbouw.
Als ik het zelf ga bouwen wordt het iig OO
Zit dan alleen nog met sql dialecten...

Eerst maar eens adodb en phpnuke doorkijken.

offtopic:
dacht dat ado alleen iets vb achtigs was

[ Voor 29% gewijzigd door DDemolition op 06-07-2006 21:00 ]

[djc]

Metabase is ook een goede. Erg grondige abstractie, erg veel databases.

(Weet niet wanneer de laatste release was, en de auteur is een van de weinige mensen die ooit van php-dev geband zijn omdat ie zo verdomd irritant was, maar dit project mag er zeker wezen.)

[XWB]

De laatste tijd ben ik vooral met de PDO class bezig. Deze ondersteunt 8 databases als ik me niet vergis.

http://wiki.cc/php/PDO_Basics
http://wiki.cc/php/PDO_Resources

Nadeel is wel dat er niet veel documentatie over te vinden is en zelf de php handleiding is niet compleet. Maar zeker de moeite waard om eens naar te kijken

[Michali]

De SQL dialecten kun je juist mooi verbergen door met objecten een query op te bouwen. Ik zal eens een voorbeeld geven van hoe je zoiets zou kunnen gebruiken.

PHP:

<?php

$query = Database::createSelectQuery();
$query->addTable('tabel1');
$query->addField('veld1');
$query->addField('veld2');
$selection = $query->getSelection();
$selection->addCondition('veld3', Operator::LIKE, 'blaat');
$resultSet = $query->execute();
while ( $record = $resultSet->fetch() )
{
    print $record->get('veld1') . ", " . $record->get('veld2') . "<br/>";
}

?>

Hoe je het allemaal implementeerd laat ik aan jou over.

[ReverendBizarre]

Sowieso moet je bij dit soort dingen gewoon zoveel mogelijk streven naar het gebruiken van portable SQL statements en dus niet te veel rare dingen uithalen.

[Genoil]

Michali schreef op vrijdag 07 juli 2006 @ 07:34:
De SQL dialecten kun je juist mooi verbergen door met objecten een query op te bouwen. Ik zal eens een voorbeeld geven van hoe je zoiets zou kunnen gebruiken.

PHP:

<?php

$query = Database::createSelectQuery();
$query->addTable('tabel1');
$query->addField('veld1');
$query->addField('veld2');
$selection = $query->getSelection();
$selection->addCondition('veld3', Operator::LIKE, 'blaat');
$resultSet = $query->execute();
while ( $record = $resultSet->fetch() )
{
    print $record->get('veld1') . ", " . $record->get('veld2') . "<br/>";
}

?>

Hoe je het allemaal implementeerd laat ik aan jou over.

Dat lijkt erg veel op Criteria van Propel (loose port van Java Torque). Propel 1.0 leunt op de Creole DAL en 2.0 wordt waarschijnlijk gebaseerd op PDO. Ik doe heel veel met Propel/Creole maar het grote nadeel vind ik wel dat het een beetje bloated is voor PHP. Dus ook niet zo vlot.

Ik heb laatst gekeken naar het CodeIgniter framework en als je ziet hoe simpel en effectief en snel daarmee kan worden gewerkt twijfel ik wel of dat moeilijke gedoe allemaal wel nodig is.

[djc]

Genoil schreef op vrijdag 07 juli 2006 @ 12:21:
Ik heb laatst gekeken naar het CodeIgniter framework en als je ziet hoe simpel en effectief en snel daarmee kan worden gewerkt twijfel ik wel of dat moeilijke gedoe allemaal wel nodig is.

Plus dat je op deze manier 10 lines aan een query verspeelt in plaats van 1, en dan is dit nog een relatief eenvoudige query.

Overigens is PDO natuurlijk wel maar een halve oplossing. De databases verschillen in veel meer opzichten dan alleen de API, en dat wordt pas echt opgelost in iets als Metabase, waar de diversiteit in abstracties pas echt goed wordt aangepakt.

[Michali]

Genoil schreef op vrijdag 07 juli 2006 @ 12:21:
[...]


Dat lijkt erg veel op Criteria van Propel (loose port van Java Torque). Propel 1.0 leunt op de Creole DAL en 2.0 wordt waarschijnlijk gebaseerd op PDO. Ik doe heel veel met Propel/Creole maar het grote nadeel vind ik wel dat het een beetje bloated is voor PHP. Dus ook niet zo vlot.

Ik heb laatst gekeken naar het CodeIgniter framework en als je ziet hoe simpel en effectief en snel daarmee kan worden gewerkt twijfel ik wel of dat moeilijke gedoe allemaal wel nodig is.

Ik vind het wel makkelijk werken zo. Overigens heb ik voor simpele queries tools geschreven zodat je het in minder regels kan:

PHP:

$selection = Database::createSelection();
$selection->addCondition('veld3', Operator::LIKE, 'blaat');
$resultSet = DBTools::simpleSelect('tabel1', array('veld1', 'veld2'), $selection);
while ( $record = $resultSet->fetch() )
{
    print $record->get('veld1') . ", " . $record->get('veld2') . "<br/>";
}

En als Operator::LIKE, Operator::EQUAL was geweest (wat meestal het geval is), dan had het zelfs zo gekund:

PHP:

$resultSet = DBTools::simpleSelect('tabel1', array('veld1', 'veld2'), array('veld3' => 'blaat'));
while ( $record = $resultSet->fetch() )
{
    print $record->get('veld1') . ", " . $record->get('veld2') . "<br/>";
}

Maar ik ga wel eens naar dat CodeIgniter kijken, ik ben er wel benieuwd naar.

[ Voor 10% gewijzigd door Michali op 07-07-2006 13:51 ]

[Genoil]

Michali schreef op vrijdag 07 juli 2006 @ 13:50:
[...]
Maar ik ga wel eens naar dat CodeIgniter kijken, ik ben er wel benieuwd naar.

CI is een soort RoR. Het DAO gedeelte is een implementatie van het ActiveRecord pattern:

http://www.codeigniter.co...tabase/active_record.html

PHP4/5:

PHP:

$this->db->select('title')
$this->db->from('mytable')
$this->db->where('id', $id)
$this->db->limit(10, 20);

Of in PHP5:

PHP:

$this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);

[Bergen]

Hier staat ook een prachtige ActiveRecord class:

http://jaws.townsville.nl/download/class.ActiveRecord.phps

en hier een implementatievoorbeeld:

http://www.daholygoat.com...aticPage&action=Page&id=8

[Norm2782]

Of kijk eens naar Zend Framework:

http://framework.zend.com

Dit heeft een hele mooie DB abstractie laag.

[DDemolition]

Heleboel goede tips hier...
Ik heb het eea doorgekeken en de dialecten zijn idd heel goed af te vangen.

Ik zal deze week een lijstje maken van alle paketten en ze eens rustig testen.