PHP Developer Forum Hier habt ihr die Möglichkeit, eure Skriptprobleme mit anderen Anwendern zu diskutieren. Seid so fair und beantwortet auch Fragen von anderen Anwendern. Dieses Forum ist sowohl für ANFÄNGER als auch für PHP-Profis! Fragen zu Laravel, YII oder anderen PHP-Frameworks. |
 |

08-06-2009, 17:49
|
Kropff
  Administrator
|
|
Registriert seit: Mar 2002
Ort: Köln
Beiträge: 11.727
|
|
PDO und hochkomplexe SQL-Abfragen
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
__________________
Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
Meine Seite
|

08-06-2009, 17:59
|
combie
PHP Expert
|
|
Registriert seit: May 2006
Beiträge: 3.296
|
|
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.
|

08-06-2009, 18:05
|
Kropff
  Administrator
|
|
Registriert seit: Mar 2002
Ort: Köln
Beiträge: 11.727
|
|
Da bin auch gerade am recherchieren. Ob nun Doctrine oder Propel. Wie gut ist denn die Abstraktionsschicht von doctrine?
peter
__________________
Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
Meine Seite
|

08-06-2009, 18:13
|
combie
PHP Expert
|
|
Registriert seit: May 2006
Beiträge: 3.296
|
|
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.....
|

08-06-2009, 18:16
|
Kropff
  Administrator
|
|
Registriert seit: Mar 2002
Ort: Köln
Beiträge: 11.727
|
|
Zitat:
Zitat von combie
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
__________________
Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
Meine Seite
|

08-06-2009, 18:21
|
combie
PHP Expert
|
|
Registriert seit: May 2006
Beiträge: 3.296
|
|
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.
|

08-06-2009, 18:36
|
Kropff
  Administrator
|
|
Registriert seit: Mar 2002
Ort: Köln
Beiträge: 11.727
|
|
ich schau mal. danke dir.
peter
__________________
Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
Meine Seite
|

08-06-2009, 19:06
|
PHP-Desaster
PHP Expert
|
|
Registriert seit: Mar 2006
Beiträge: 3.105
|
|
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.
|

08-06-2009, 20:28
|
Kropff
  Administrator
|
|
Registriert seit: Mar 2002
Ort: Köln
Beiträge: 11.727
|
|
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
__________________
Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
Meine Seite
|

08-06-2009, 20:55
|
asp2php
Banned
|
|
Registriert seit: Feb 2004
Beiträge: 11.745
|
|
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
|

08-06-2009, 21:08
|
ezkimo
Registrierter Benutzer
|
|
Registriert seit: Apr 2005
Ort: Beckum / Westf.
Beiträge: 279
|
|
Zitat:
Zitat von asp2php
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.
|

08-06-2009, 21:26
|
Kropff
  Administrator
|
|
Registriert seit: Mar 2002
Ort: Köln
Beiträge: 11.727
|
|
Zitat:
Zitat von ezkimo
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.
Zitat:
Zitat von 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 
|
Naja, die Performance ist das Wichtigste. Da werden wir wohl in den sauren Apfel beißen müssen.
Peter
__________________
Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
Meine Seite
|

08-06-2009, 21:34
|
PHP-Desaster
PHP Expert
|
|
Registriert seit: Mar 2006
Beiträge: 3.105
|
|
Zitat:
Zitat von ezkimo
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:
PHP-Code:
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');
|

09-06-2009, 13:56
|
ezkimo
Registrierter Benutzer
|
|
Registriert seit: Apr 2005
Ort: Beckum / Westf.
Beiträge: 279
|
|
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:
Zitat:
Zitat von Manual
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?
|
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
|
|
Themen-Optionen |
|
Thema bewerten |
|
Forumregeln
|
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.
HTML-Code ist aus.
|
|
|
|
PHP News
|