nicht angemeldet
Zend DB
Hallo,
ich bin am überlegen ob ich Zend DB für den Zugriff auf meine Mysql / SQL Datenbanken verwende.
Gibt es da große Geschwindigkeitseinbußen die Abfragen darüber zu machen, als wenn man die Abfragen direkt an den MYSQL schickt?
Ich habe gehört, dass z.B. eine andere Lib ADOdb recht langsam sein soll?
Kann man dann wirklich einfach mit demselben Code zwischen MYSQL und MSSQL wechseln?
Gruß
martin
-
你好 martin22,
Kann man dann wirklich einfach mit demselben Code zwischen MYSQL und MSSQL wechseln?
Das hängt im Wesentlichen von deinen SQL-Statements ab. Die SQL-Dialekte der verschiedenen Datenbanken unterscheiden sich ja teilweise sehr stark, darauf musst du selber achten.
再见,
克里斯蒂安--
http://wwwtech.de/
Wayne Revived | Unix rocks!
Unsere Vorstellungen von der Ewigkeit sind genauso nuetlich wie die Mutmassungen eines Kuekens ueber die Aussenwelt bevor es die Eierschale aufbricht.
-
Moin!
ich bin am überlegen ob ich Zend DB für den Zugriff auf meine Mysql / SQL Datenbanken verwende.
Gerade Zend_DB ist aus dem Gesamtframework nach Meinung einiger Experten der schlechtere Teil. Ich konnte mir dazu noch keine eigene Meinung bilden.
Gibt es da große Geschwindigkeitseinbußen die Abfragen darüber zu machen, als wenn man die Abfragen direkt an den MYSQL schickt?
Kein Zwischenlayer geht spurlos an der Geschwindigkeit vorüber, aber das sollte erst einmal nicht deine primäre Sorge sein. Performanceprobleme werden dann gelöst, wenn sie auftreten, und speziell abgestimmt auf das tatsächliche Problem.
Ich habe gehört, dass z.B. eine andere Lib ADOdb recht langsam sein soll?
Kann sein, hielte ich aber für eher irrelevant.
Kann man dann wirklich einfach mit demselben Code zwischen MYSQL und MSSQL wechseln?
Sowas funktioniert nur in seltenen Fällen - nämlich wenn du nur die Features nutzt, die von allen beabsichtigten Datenbanken unterstützt werden. Manche fehlenden Features könnten eventuell auch vom DB-Layer manuell nachgebaut werden, aber effektiv betrachtet sind die Datenbanken nun mal unterschiedlich ausgestattet - und das hat seinen Grund ja gerade deshalb, weil diese Unterschiede gebraucht werden.
- Sven Rautenberg
-
Hellihello Sven,
Gerade Zend_DB ist aus dem Gesamtframework nach Meinung einiger Experten der schlechtere Teil.
Hast Du Weblinks dazu?
Ich konnte mir dazu noch keine eigene Meinung bilden.
http://framework.zend.com/apidoc/core/ bzw. http://framework.zend.com/manual/en/zend.db.html lassen doch sicher schnell ein Urteil zu, wenn man weiß, worauf es ankommt, oder?
Dank und Gruß,
-
Moin!
Gerade Zend_DB ist aus dem Gesamtframework nach Meinung einiger Experten der schlechtere Teil.
Hast Du Weblinks dazu?
Ich konnte mir dazu noch keine eigene Meinung bilden.
Diese Meinung wurde mir mündlich übermittelt. :) Also keine Weblinks, obwohl nicht auszuschließen ist, dass sich auch online Meinungen dazu finden lassen.
http://framework.zend.com/apidoc/core/ bzw. http://framework.zend.com/manual/en/zend.db.html lassen doch sicher schnell ein Urteil zu, wenn man weiß, worauf es ankommt, oder?
Ich denke, die geäußerte Kritik bezog sich eher nicht auf das angebotene Interface, sondern auf die interne Arbeitsweise bzw. dessen Verhalten in größeren Applikationen. Wo genau das Problem liegen soll, habe ich bislang nicht näher erforschen können.
- Sven Rautenberg
-
Hellihello Sven
Hast Du Weblinks dazu?
Ich konnte mir dazu noch keine eigene Meinung bilden.
Diese Meinung wurde mir mündlich übermittelt. :) Also keine Weblinks, obwohl nicht auszuschließen ist, dass sich auch online Meinungen dazu finden lassen.
Mussich morgen mal suchen. Heute unterwegs.
Ich denke, die geäußerte Kritik bezog sich eher nicht auf das angebotene Interface, sondern auf die interne Arbeitsweise bzw. dessen Verhalten in größeren Applikationen.
Was ist denn die "interne Arbeitsweise" und "dessen Verhalten in ""größeren Applikationen""?
Was hat die interne Arbeitsweise mit der größe der Gesamtapplikation zu tun? Was überhaupt meinst Du mit "interner Arbeitsweise"? Die Methoden der Klassen?
Sowas wie ORM o.äh. findet da ja garnicht statt.
Dank und Gruß,
-
Hellihello Sven,
Hast Du Weblinks dazu?
Ich konnte mir dazu noch keine eigene Meinung bilden.
Diese Meinung wurde mir mündlich übermittelt. :) Also keine Weblinks, obwohl nicht auszuschließen ist, dass sich auch online Meinungen dazu finden lassen.
Mussich morgen mal suchen. Heute unterwegs.
http://www.zend.com/forums/index.php?t=msg&goto=6834
"A bit of a difficult question to answer but generally, yes Zend_Db/framework does appear to have quite reasonable performance on larger sites in my experience.
This of course depends on the way it is used, as is the case with all development, it's perfectly possible to have terrible performance with the best code if it is not used optimally."
http://www.havelsoft.org/tutorials/ZF_Doctrine.pdf
"Zend_Db ist keine schlechte Sache, es ist halt eine low-level
Abstraktion und sehr nahe an den Datenbank-Engines programmiert."Vielleicht kannst Du ja doch nochmal sagen, was genau mit "der schlechtere Teil" gemeint ist.
Ich denke, die geäußerte Kritik bezog sich eher nicht auf das angebotene Interface, sondern auf die interne Arbeitsweise bzw. dessen Verhalten in größeren Applikationen.
Was ist denn die "interne Arbeitsweise" und "dessen Verhalten in ""größeren Applikationen""?
Was hat die interne Arbeitsweise mit der größe der Gesamtapplikation zu tun? Was überhaupt meinst Du mit "interner Arbeitsweise"? Die Methoden der Klassen?
Sowas wie ORM o.äh. findet da ja garnicht statt.
Stattdessen:
"Zend_Db and its related classes provide a simple SQL database interface for Zend Framework. The
Zend_Db_Adapter is the basic class you use to connect your PHP application to an RDBMS. There is a
different Adapter class for each brand of RDBMS.""Creating an instance of an Adapter class does not immediately connect to the RDBMS server. The Adapter
saves the connection parameters, and makes the actual connection on demand, the first time you need to
execute a query. This ensures that creating an Adapter object is quick and inexpensive."(aus http://framework.zend.com/manual/en/zend.db.html).
Es würde mich wirklich interessieren, wo dort Schwachstellen auszumachen sind, da es sich nach meinem Verständnis ja "lediglich" um eine Schnittstelle zu den "üblichen" PHP-eigenen Funktionen. Was ist denn da die "interne" Arbeitsweise? Schlussendlich nutzen setzen die Klassen doch ganz normal queries an die DB ab. Was könnte man denn da denn anders machen?
Dank und Gruß,
-
Hellihello Sven,
es wäre schön, wenn Du kurz nochmal antworten würdest. Ich konnte im Netz nichts zu Deiner Aussage finden, und sie verwirrt mich auch, da das Framework ja lediglich die PHP-Funktionen in Klassen einbettet. Da ich Deine sonstigen Beiträge ob ihrer Qualität bisher immer sehr geschätzt habe, denke ich, ich könnte vielleicht was übersehen oder falsch verstanden haben.
Frage also auch noch andersherum: sind die Zend_DB-Klassen nicht auch "nur" eine variante der PEAR-Klassen? (Ich rede jetzt nicht von PEARs PHP4-Kompatibilität sondern vom Prinzip). Ich rätsel immer noch, was mit "der schlechtere Teil" und Problemen bei "größeren Applikationen" gemeint sein könnte.
Mir geht es auch schon um eine pauschale Einschätzung des Frameworks, als (business-) Alternative zu Rails, Symphony, Cake, Django.
Im Voraus schon Dank für etwaige Mühen,
Robert aka
-
Moin!
es wäre schön, wenn Du kurz nochmal antworten würdest. Ich konnte im Netz nichts zu Deiner Aussage finden, und sie verwirrt mich auch, da das Framework ja lediglich die PHP-Funktionen in Klassen einbettet. Da ich Deine sonstigen Beiträge ob ihrer Qualität bisher immer sehr geschätzt habe, denke ich, ich könnte vielleicht was übersehen oder falsch verstanden haben.
Ich möchte betonen, dass ich direkt von Anfang an nur die Meinung Dritter wiedergegeben habe, und ebenfalls hinzugefügt, dass ich meine eigene Meinung dazu noch nicht bilden konnte.
Wenn du jetzt also keine Belege findest, kann das entweder daran liegen, dass es zur Niederschrift keinen Anlass gab, weil Zend_DB doch toll ist, oder dass die schlechten Seiten bislang von der Masse an Entwicklern noch nicht entdeckt wurden, weil die nicht so tief eingestiegen sind.
Meine persönliche Kritik am Zend-Framework zielt, basierend auf eigener Erfahrung, vielmehr gegen Zend_Validate & Co. Der Part ist, zumindest in Version 1.5, noch so richtig von Übel, wie ich finde.
Frage also auch noch andersherum: sind die Zend_DB-Klassen nicht auch "nur" eine variante der PEAR-Klassen? (Ich rede jetzt nicht von PEARs PHP4-Kompatibilität sondern vom Prinzip). Ich rätsel immer noch, was mit "der schlechtere Teil" und Problemen bei "größeren Applikationen" gemeint sein könnte.
Ich hab keine Ahnung, warum man zur Meinung gelangte, Zend_DB wäre eher schlechter.
Mir geht es auch schon um eine pauschale Einschätzung des Frameworks, als (business-) Alternative zu Rails, Symphony, Cake, Django.
Da kann ich dir nicht wirklich weiterhelfen.
- Sven Rautenberg
-
Hellihello Sven,
Ich möchte betonen, dass ich direkt von Anfang an nur die Meinung Dritter wiedergegeben habe, und ebenfalls hinzugefügt, dass ich meine eigene Meinung dazu noch nicht bilden konnte.
Merci, das hatte ich schon kapiert. Aber "Dritte" tauchen ja _u.U._ wieder auf, oder geben nochmal einen Kommentar oder lassen sich näher spezifizieren. (;-).
Wenn du jetzt also keine Belege findest, kann das entweder daran liegen, dass es zur Niederschrift keinen Anlass gab, weil Zend_DB doch toll ist, oder dass die schlechten Seiten bislang von der Masse an Entwicklern noch nicht entdeckt wurden, weil die nicht so tief eingestiegen sind.
Ja, und darauf zielt doch meine Frage: die Klassen sind doch nichts weiter als eine Verpackung für mysqli-Funktionen. Wie soll das bei größeren Applikationen problematisch werden?
Meine persönliche Kritik am Zend-Framework zielt, basierend auf eigener Erfahrung, vielmehr gegen Zend_Validate & Co. Der Part ist, zumindest in Version 1.5, noch so richtig von Übel, wie ich finde.
Magst Du "so richtig von Übel" noch mit ein paar Stichworten bebildern?
Frage also auch noch andersherum: sind die Zend_DB-Klassen nicht auch "nur" eine variante der PEAR-Klassen? (Ich rede jetzt nicht von PEARs PHP4-Kompatibilität sondern vom Prinzip). Ich rätsel immer noch, was mit "der schlechtere Teil" und Problemen bei "größeren Applikationen" gemeint sein könnte.
Ich hab keine Ahnung, warum man zur Meinung gelangte, Zend_DB wäre eher schlechter.
Mh, weil das ja die Meinung eines dritten war. Den gibts hier im Forum aber scheinbar nicht, oder?
Mir geht es auch schon um eine pauschale Einschätzung des Frameworks, als (business-) Alternative zu Rails, Symphony, Cake, Django.
Da kann ich dir nicht wirklich weiterhelfen.
Schade(;-), aber Danke für die Infos.
Dank und Gruß,
-
Moin!
Ich möchte betonen, dass ich direkt von Anfang an nur die Meinung Dritter wiedergegeben habe, und ebenfalls hinzugefügt, dass ich meine eigene Meinung dazu noch nicht bilden konnte.
Merci, das hatte ich schon kapiert. Aber "Dritte" tauchen ja _u.U._ wieder auf, oder geben nochmal einen Kommentar oder lassen sich näher spezifizieren. (;-).
Aber nicht vor Februar. :)
Wenn du jetzt also keine Belege findest, kann das entweder daran liegen, dass es zur Niederschrift keinen Anlass gab, weil Zend_DB doch toll ist, oder dass die schlechten Seiten bislang von der Masse an Entwicklern noch nicht entdeckt wurden, weil die nicht so tief eingestiegen sind.
Ja, und darauf zielt doch meine Frage: die Klassen sind doch nichts weiter als eine Verpackung für mysqli-Funktionen. Wie soll das bei größeren Applikationen problematisch werden?
Nein, Zend_DB kann ganz verschiedene DB-Anbindungen nutzen, sowohl mysqli, als auch PDO, als auch alle möglichen anderen Datenbanken.
Dementsprechend ist die Verpackung also etwas komplexer, als nur ein Wrapper für eine bestehende mysqli-Funktion bzw. -Methode (mysqli wendet man, wenn man OOP nutzt, ja sowieso besser als Objekt an).
Meine persönliche Kritik am Zend-Framework zielt, basierend auf eigener Erfahrung, vielmehr gegen Zend_Validate & Co. Der Part ist, zumindest in Version 1.5, noch so richtig von Übel, wie ich finde.
Magst Du "so richtig von Übel" noch mit ein paar Stichworten bebildern?
Die Verwendung von Zend_Filter_Input zusammen mit den diversen Zend_Validate-Checkern ist zumindest in 1.5 nur als "eklig" zu bezeichnen. Mein Ziel war es, passend zu einem $_POST-Array ein zugehöriges Validations-Array mit allen notwendigen Angaben zu vorzunehmenden Prüfungen zu schreiben, so dass die eigentliche Prüfung sich darauf reduzieren sollte, $_POST und das Validate-Array in einem Prüfschritt zusammenzubringen und hinterher die Ergebnisse auszuwerten, d.h. fehlerhafte Felder per Affenformular anzumeckern, oder gültige Daten weiterzuverarbeiten.
Als problematisch hat sich dabei herausgestellt, dass selbst verhältnismäßig schlichte Prüfanforderungen in ein extrem unübersichtliches Validate-Array ausarten. Darüber hinaus funktionierte in 1.5 auch nur ein kleiner Teil der zentralen Konfiguration für generische Fehlermeldungen (was bedeutet, dass für einen anderen Typ von Fehlermeldung jeder einzelne verwendete Validator diese Meldung eigenständig konfiguriert bekommen mußte, was wiederum das Validator-Array extrem aufgebläht hätte)...
Ja, vielleicht hilft es, anstelle von Zend_Filter_Input (zusammen mit der Smarty-Template-Engine) lieber direkt Zend_Form zu verwenden - aber das läuft dann doch etwas der Idee entgegen, dass das Zend-Framework eben nur kombinierbare Einzelteile zur Verfügung stellt.
- Sven Rautenberg
-
Hellihello
Ich möchte betonen, dass ich direkt von Anfang an nur die Meinung Dritter wiedergegeben habe, und ebenfalls hinzugefügt, dass ich meine eigene Meinung dazu noch nicht bilden konnte.
Merci, das hatte ich schon kapiert. Aber "Dritte" tauchen ja _u.U._ wieder auf, oder geben nochmal einen Kommentar oder lassen sich näher spezifizieren. (;-).
Aber nicht vor Februar. :)
Ich kann warten (;-).
Dementsprechend ist die Verpackung also etwas komplexer, als nur ein Wrapper für eine bestehende mysqli-Funktion bzw. -Methode (mysqli wendet man, wenn man OOP nutzt, ja sowieso besser als Objekt an).
Eben, das meinte ich. Wenn man mysql eben benutzt, und nichts anderes.
Meine persönliche Kritik am Zend-Framework zielt, basierend auf eigener Erfahrung, vielmehr gegen Zend_Validate & Co. Der Part ist, zumindest in Version 1.5, noch so richtig von Übel, wie ich finde.
Magst Du "so richtig von Übel" noch mit ein paar Stichworten bebildern?
Die Verwendung von Zend_Filter_Input zusammen mit den diversen Zend_Validate-Checkern ist zumindest in 1.5 nur als "eklig" zu bezeichnen. Mein Ziel war es, passend zu einem $_POST-Array ein zugehöriges Validations-Array mit allen notwendigen Angaben zu vorzunehmenden Prüfungen zu schreiben, so dass die eigentliche Prüfung sich darauf reduzieren sollte, $_POST und das Validate-Array in einem Prüfschritt zusammenzubringen und hinterher die Ergebnisse auszuwerten, d.h. fehlerhafte Felder per Affenformular anzumeckern, oder gültige Daten weiterzuverarbeiten.
Bisher hatte ich mich nur mit dem Lesen von Zend_Form beschäftigt und eigentlich gedacht, dass all das, was Du schreibst, gut gehen sollte.
Als problematisch hat sich dabei herausgestellt, dass selbst verhältnismäßig schlichte Prüfanforderungen in ein extrem unübersichtliches Validate-Array ausarten.
Hattest Du Dir überlegt, dass in eine Zend_Config-Klasse/Datei auszulagern. XML oder ini wären zwei Varianten, die mir untergekommen sind.
Darüber hinaus funktionierte in 1.5 auch nur ein kleiner Teil der zentralen Konfiguration für generische Fehlermeldungen (was bedeutet, dass für einen anderen Typ von Fehlermeldung jeder einzelne verwendete Validator diese Meldung eigenständig konfiguriert bekommen mußte, was wiederum das Validator-Array extrem aufgebläht hätte)...
OOps, vielleicht "lügt" ja die Doku zu 1.6, oder es gab einen Quantensprung, oder ich habs nicht kapiert.
Ja, vielleicht hilft es, anstelle von Zend_Filter_Input (zusammen mit der Smarty-Template-Engine) lieber direkt Zend_Form zu verwenden - aber das läuft dann doch etwas der Idee entgegen, dass das Zend-Framework eben nur kombinierbare Einzelteile zur Verfügung stellt.
Jau, eigentlich sollte man die Einzelteile alle prima einzeln nutzen können. So verstand ich die Doku bisher und auch die einzelnen Testversuche, die ich unternommen hatte.
Dank und Gruß,
-
-
-
-
-
-
-
-
-