PDO und hochkomplexe SQL-Abfragen

[Kropff]

Eine Frage dazu. Hat irgend jemand von euch schon schlechte Erfahrungen mit PDO gemacht, wenn die Abfragen richtig heftig waren? Also die berühmten 100-Zeilen-Abfragen. Mehrfache JOINS, mehrere UNIONS und so weiter und so fort. Habe auch gelesen, dass PDO keine vernünftige numrows unterstützung hat. Gibt es sonst noch Kritikpunkte daran?

Zur Info. Wir stellen gerade eine Anwendung um und möchten mehr Datenbanken unterstützen als nur MySQL. Aber wie ich schon sagte, ein Teil der Logik basiert auf diesen Monsterabfragen. Und wenn PDO da Schwächen hat, können wir es nicht nutzen.

Peter

[combie]

Nee, nicht wirklich..
Meist nutze ich PDO nur indirekt, wegen der fehlenden SQL Abstaktion. Das grenzt die Portabilität doch ganz schön ein. Doctrine bietet da einiges "mehr" und setzt auf PDO auf.

Einmal sind mir "Memory Leaks" aufgefallen. Das war allerdings ein Dauerläufer Script und die Probleme traten erst nach Stunden auf. Dürfte für Webanwendungen also nicht relevant sein.

[Kropff]

Da bin auch gerade am recherchieren. Ob nun Doctrine oder Propel. Wie gut ist denn die Abstraktionsschicht von doctrine?

peter

[combie]

Wie gut?
Gewöhnungsbedürftig, aber genial!
Ich bin bisher noch nicht an Grenzen gestoßen.

Das meiste versuche ich mit Templates und dem "actAs" Konzept abzuhandeln.
Aber auch das DQL ist relativ leicht zu nutzen.

Versuchs doch einfach mal.....

[Kropff]

Versuchs doch einfach mal.....

Also einfach mal versuchen, dürfte bei diesem Projekt ein wenig heikel sein. Da müssen wir uns vorher entscheiden.

Peter

[combie]

Ich meine mehr "warmlaufen" und "gewöhnen". Ein paar Modelle anlegen und deine fetten Querys testen. Dann siehste auch wie performant das wird.
Ohne Probelauf, würde ich die Entscheidung nicht fällen.

[Kropff]

ich schau mal. danke dir.

peter

[PHP-Desaster]

Als gute Alternative zu Doctrine ist noch Zend_Db_Table zu erwähnen. Nicht ganz so umständlich mit den Yaml-Dateien, abstrahiert dafür aber auch nicht bis auf eigene Modelklassen sondern nur auf Datensatzebene, diese verfügen aber auch über Funktionen wie save, delete, update, etc. Weiter hast du mit den Statement-Klassen etwas ähnliches wie DQL. Wenn du eh das Zend-Framework nutzt, die bessere Alternative, da du dir damit auch eine Projektabhängigkeit zu Doctrine sparen kannst.

[Kropff]

also ich glaube für die einarbeitung in zend fehlt uns die zeit. ein paar von uns (einschließlich meine wenigkeit) haben sich damit schon beschäftigt. aber ob uns für eine komplette einarbeitung genug zeit bleibt, ist fraglich. außerdem neigen frameworks dazu, nicht besonders performant zu sein. und das ist hier besonders wichtig.

peter

[asp2php]

Peter, Framework oder nicht, jeder Abtract Layer ist langsamer als direkt, dafür ist es bequemer. Du mußt schon das kleinere Übel für dein Projekt in Kauf nehmen. Also entweder alle Module einzeln je nach DBMS schreiben und bei Bedarf einsetzen/austauschen, oder allgemeine Module für alle unterstützten DBMS dafür aber etwas langsamer. Was für euch das kleinere Übel ist, müßt ihr wissen

[ezkimo]

Also entweder alle Module einzeln je nach DBMS schreiben und bei Bedarf einsetzen/austauschen ...

Aber liegt hier nicht genau einer der Vorteile von PDO? Die Abstraktion fällt doch komplett weg. Zudem dürfte PDO um einiges schneller laufen als jede in PHP programmierte Datenbank-Klasse oder ein PHP Framework, da PDO direkt in C geschrieben ist und nicht erst über PHP kompiliert werden muss.

Ich persönlich setze PDO unter anderem in einem Kundenverwaltungstool mit nun mehr als 400.000 Datensätzen und einem Db Volumen von knapp 2GB ein. Darunter auch sehr komplexe Abfragen mit mehreren Joins, SubSelects, etc.

Das mit der fehlerhaften Handhabe von numrows ist so eine Sache. Sofern es sich nicht um ein Select Query handelt, funktioniert das PDOStatement::rowCount() ohne Probleme. Bei Select Queries habe ich mir angewöhnt mit SELECT COUNT(*) zu arbeiten.. Hierin sehe ich aber auch kein grundlegendes Problem, welches PDO unattraktiver macht.

Also ich kann es aus Erfahrung raus nur empfehlen und bin hier auf noch keine größeren Probleme gestoßen.

[Kropff]

Ich persönlich setze PDO unter anderem in einem Kundenverwaltungstool mit nun mehr als 400.000 Datensätzen und einem Db Volumen von knapp 2GB ein. Darunter auch sehr komplexe Abfragen mit mehreren Joins, SubSelects, etc.

Bei uns wird es wohl noch einges mehr werden. Die aktuelle Anwendung umfasst etwa 20 GB in der DB. Und die Anzahl der Datensätze ist auch viel, viel größer.

Peter, Framework oder nicht, jeder Abtract Layer ist langsamer als direkt, dafür ist es bequemer. Du mußt schon das kleinere Übel für dein Projekt in Kauf nehmen. Also entweder alle Module einzeln je nach DBMS schreiben und bei Bedarf einsetzen/austauschen, oder allgemeine Module für alle unterstützten DBMS dafür aber etwas langsamer. Was für euch das kleinere Übel ist, müßt ihr wissen

Naja, die Performance ist das Wichtigste. Da werden wir wohl in den sauren Apfel beißen müssen.

Peter

[PHP-Desaster]

Aber liegt hier nicht genau einer der Vorteile von PDO? Die Abstraktion fällt doch komplett weg. Zudem dürfte PDO um einiges schneller laufen als jede in PHP programmierte Datenbank-Klasse oder ein PHP Framework, da PDO direkt in C geschrieben ist und nicht erst über PHP kompiliert werden muss.

Zend_Db_Table setzt ja erst auf PDO (unter anderem, Zend_Db kann auch zum Beispiel die mysql-Extension ohne PDO nutzen) auf. Was man noch machen könnte wäre, alle SQL-Statements auszulagern und über einen kleinen Wrapper dynamisch über IDs zu laden. Das Binden von Parametern geschieht ja über die bind*-Methoden. Sowas in die Richtung:

class MyPDO {
private $_sqlDir;
private $_pdo;
public function prepareQuery($id) {
    if($this->_cache===NULL) {
        $db=$this->_pdo->getAttribute(PDO::ATTR_DRIVER_NAME);
        $file=$this->_sqlDir.$db.'.php';
        if(!is_file($file)) {
            throw new FileNotFoundException('File '.$file.' not found');
        }
        $this->_cache=include $file;
    }
    if(!isset($this->_cache[$id])) {
        throw new InvalidArgumentException('No query for id '.$id.' found');
    }
    return $this->prepare($this->_cache[$id]);
}
}

$db=new MyPDO(/*...*/'/path/to/queries/');
$stmt=$db->prepareQuery('MyQueryID'); 

[ezkimo]

Der Ansatz ist sicherlich gut. Ich bin mir jetzt aber nicht ganz sicher, ob das interne Caching bzgl. der prepared Statements diesen Job nicht ohnehin übernimmt:

Calling PDO:repare() and PDOStatement::execute() for statements that will be issued multiple times with different parameter values optimizes the performance of your application by allowing the driver to negotiate client and/or server side caching of the query plan ...

Sicherlich bezieht sich dieser Teil auf die Festsetzung des Statements während der Laufzeit. Die Frage wäre jetzt, ob dies auch über die Laufzeit eines Scripts hinaus gilt?