Hallo newsgroup,
welchen Kandidaten würdet Ihr bzgl. Database Abstraction Layer bevorzugen:
a) Zend Framework
b) Pear::MDB2
c) Pear::DB
d) other
....und warum?
Die ersten beiden stehen unter BSD-Lizenz und Pear:DB unter PHP-Lizenz.
Lieben Gruß
Daniela Waranie
Daniela Waranie schrieb:
> Hallo newsgroup,
Hi,
> welchen Kandidaten würdet Ihr bzgl. Database Abstraction Layer bevorzugen:
e) PDO
Nutze ich derzeit und sehe kein Grund auf einen Drittanbieter zu
wechseln. Das Ganze hab ich allerdings gekapselt in eine eigene Klassen
die jeweilige Schnittstellen implementieren (Connection, Prepared und
Resultset), sodass ich beliebige andere Datenbanklayer hinzufügen kann
ohne die Anwendung zu ändern.
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Christoph Herrmann schrieb:
>> welchen Kandidaten würdet Ihr bzgl. Database Abstraction Layer
>> bevorzugen:
>
> e) PDO
>
> Nutze ich derzeit und sehe kein Grund auf einen Drittanbieter zu
> wechseln. Das Ganze hab ich allerdings gekapselt in eine eigene Klassen
> die jeweilige Schnittstellen implementieren (Connection, Prepared und
> Resultset), sodass ich beliebige andere Datenbanklayer hinzufügen kann
> ohne die Anwendung zu ändern.
Wobei man hier auch gleich beachten kann, dass das Zend Framework
ebenfalls PDO benutzt. Weiterhin bringt es die Herstellerunabhängigkeit
auch gleich mit.
Gruß,
Hilmar
Hilmar Bunjes schrieb:
> Wobei man hier auch gleich beachten kann, dass das Zend Framework
> ebenfalls PDO benutzt. Weiterhin bringt es die Herstellerunabhängigkeit
> auch gleich mit.
Welche Herstellerunabhängigkeit?
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Christoph Herrmann schrieb:
> Hilmar Bunjes schrieb:
>> Wobei man hier auch gleich beachten kann, dass das Zend Framework
>> ebenfalls PDO benutzt. Weiterhin bringt es die
>> Herstellerunabhängigkeit auch gleich mit.
>
> Welche Herstellerunabhängigkeit?
Oh, sorry. Ich hatte bei deiner Antwort verstanden, dass du mit deiner
Kapselung herstellerunabhängig und nicht DAL-unabhängig sein wolltest.
Gruß,
Hilmar
Hilmar Bunjes schrieb:
> Oh, sorry. Ich hatte bei deiner Antwort verstanden, dass du mit deiner
> Kapselung herstellerunabhängig und nicht DAL-unabhängig sein wolltest.
Durch die Kapselung lasse ich mir die Möglichkeit offen andere
Datenbanken zu unterstützen, die von PDO nicht unterstützt werden
bisher. PDO lässt sich dahingehend (soweit mir bekannt) ja nicht über
neue PHP Klassen erweitern, was mich dann wieder abhängig davon machen
würde, was PDO mir bietet.
Außerdem mag ich noch paar wichtige Dinge haben, die PDO nicht kann wie
über die Connection die Liste aller Tabellen der Datenbank holen oder
von einem Resultset einfach die erste Zelle (schön für count(*) Sachen)
bzw. allgemein die Trennung Prepared Statement und Resultset.
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Christoph Herrmann schrieb:
> Außerdem mag ich noch paar wichtige Dinge haben, die PDO nicht kann wie
> über die Connection die Liste aller Tabellen der Datenbank holen
Das habe ich bei PDO auch noch nicht gesehen. Aber für sowas verwende
ich jetzt das Zend Framework. Klappt bei mir hervorragend für so
ziemlich alles, was ich brauche.
> oder von einem Resultset einfach die erste Zelle (schön für count(*)
> Sachen)
Meinst du sowas ähnliches, was
string PDOStatement::fetchColumn ([ int $column_number ] )
macht? Es wird halt die Zelle der nächsten Zeile genommen, aber wenn
sowieso nur eine zurückgegeben wird, wäre das ja egal.
Gruß,
Hilmar
Hilmar Bunjes schrieb:
> Das habe ich bei PDO auch noch nicht gesehen. Aber für sowas verwende
> ich jetzt das Zend Framework. Klappt bei mir hervorragend für so
> ziemlich alles, was ich brauche.
Wie macht es denn Zend Framework? Gibt ja keinen wirklichen Standard
dafür die Tabellen zu ermitteln, daher macht es Zend dann für jede
Datenbank über ein anderes Statement?
> Meinst du sowas ähnliches, was
> string PDOStatement::fetchColumn ([ int $column_number ] )
> macht? Es wird halt die Zelle der nächsten Zeile genommen, aber wenn
> sowieso nur eine zurückgegeben wird, wäre das ja egal.
noch gar nicht gesehen, dass es so auch geht. ^^ Aber ja das meint ich,
ich nehme den Wert der ersten Spalte der ersten Zeile.
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Daniela Waranie wrote:
> welchen Kandidaten würdet Ihr bzgl. Database Abstraction Layer bevorzugen:
> a) Zend Framework
> b) Pear::MDB2
> c) Pear::DB
> d) other
d) bei mir. Pear würde ich sowieso keinen empfehlen, da nur PHP4.
Im Endeffekt hab ich mir auch ne Kapselung für PDO geschrieben.
> ...und warum?
Weil mich Zends Version und Pear nicht anspricht. Aber hier ist wie bei
allen anderen Dingen auch. Nur wers selbst probiert hat kann sich ein
Urteil erlauben. Urteile Anderer sind da eher sekundär und differieren
teilweise stark.
Was ich damit meine ist das Fragen wie Deine, einfach nicht
zufriedenstellend zu beantworten sind da hier jeder andere Anforderungen
stellt.
MfG, Ulf
Christoph Herrmann schrieb:
>> Das habe ich bei PDO auch noch nicht gesehen. Aber für sowas verwende
>> ich jetzt das Zend Framework. Klappt bei mir hervorragend für so
>> ziemlich alles, was ich brauche.
>
> Wie macht es denn Zend Framework? Gibt ja keinen wirklichen Standard
> dafür die Tabellen zu ermitteln, daher macht es Zend dann für jede
> Datenbank über ein anderes Statement?
Ja, macht es. Als Benutzer bekommt man davon verständlicherweise wenig
von mit:
http://framework.zend.com/manual/en/zend.db.html#zend.db.ada pter.list-describe
Gruß,
Hilmar
Hallo Ulf,
> d) bei mir. Pear würde ich sowieso keinen empfehlen, da nur PHP4.
Dein Tipp zu Pear war wirklich gut - ich hatte es schon ganz vergessen, dass
die immer noch auf PHP4 entwickeln...
> Im Endeffekt hab ich mir auch ne Kapselung für PDO geschrieben.
....vor einer Abstractions Schicht steht jeder Programmierer irgendwann. Aber
warum immer das Rad neuerfinden - statt stabilen / validierten Code
einzusetzen bzw. zu erweitern (Open Source Projekte).
> Urteile Anderer sind da eher sekundär und differieren teilweise stark.
....mir ist eine zusätzliche, fremde Meinung wichtig.
Danke für Dein Input.
Lieben Gruß
Daniela Waranie
Daniela Waranie schrieb:
> welchen Kandidaten würdet Ihr bzgl. Database Abstraction Layer bevorzugen:
> a) Zend Framework
> b) Pear::MDB2
> c) Pear::DB
> d) other
>
> ...und warum?
Nachdem meine Meinung zum Zend Framework vielleicht in der Diskussion
mit Christoph klar wurde: Ich würde zu a) tendieren (bzw. habe es auch
kürzlich gewählt).
Ich war einige Zeit nicht mehr in der PHP Entwicklung aktiv und bin
jetzt zu PHP 5.1 Zeiten wieder eingestiegen. Am Zend Framework (und dort
für die Datenbanken) fand ich die extrem einfache Handhabung sehr schön.
Alles, was ich benötigt, wird abgedeckt und ist sehr intuitiv zu
benutzen. Da ich für andere Anwendungen ebenfalls mich für Zend
entschieden habe, lag das vielleicht auch nahe.
Gruß,
Hilmar
Am 14. April 2008 schrieb Ulf Kadner:
> Daniela Waranie wrote:
>
>> welchen Kandidaten würdet Ihr bzgl. Database Abstraction Layer bevorzugen:
>> a) Zend Framework
>> b) Pear::MDB2
>> c) Pear::DB
>> d) other
>
> d) bei mir. Pear würde ich sowieso keinen empfehlen, da nur PHP4.
*gähn*, auch durch Wiederholung wird das nicht richtig.
Gruß
Mark
--
Ernst Kuzorra auf die Frage des schwedischen Königs, wo Gelsenkirchen
liege: "Bei Schalke."
Mark Wiesemann wrote:
>> d) bei mir. Pear würde ich sowieso keinen empfehlen, da nur PHP4.
>
> *gähn*, auch durch Wiederholung wird das nicht richtig.
Ja? Ganz schön grossen Mund für das wenige dahinter. Nur weil da
neuerdings vieleicht nen paar Packete PHP5 sind (welche sind das bitte?)
ists im Endeffekt immernoch abhängig von PHP4. (compiliance_mode mal
aussen vor gelassen)
Ich hab ausserdem bisher noch kein PHP5 Packet für PEAR gesehen. Zeigs
mir! Aber erzähl jetzt nix von PEAR2!
Ulf Kadner wrote:
Hallo,
> Mark Wiesemann wrote:
>>> d) bei mir. Pear würde ich sowieso keinen empfehlen, da nur PHP4.=
>>=20
>> *gähn*, auch durch Wiederholung wird das nicht richtig.
>=20
> Ja? Ganz schön grossen Mund für das wenige dahinter. Nur weil da
> neuerdings vieleicht nen paar Packete PHP5 sind (welche sind das bitt=
e?)
> ists im Endeffekt immernoch abhängig von PHP4. (compiliance_mode ma=
l
> aussen vor gelassen)
>=20
> Ich hab ausserdem bisher noch kein PHP5 Packet für PEAR gesehen. Ze=
igs
> mir! Aber erzähl jetzt nix von PEAR2!
- Hinreichend gut programmierte oder aktualisierte PEAR-Pakete laufen
unter PHP 5 bei E_ALL | E_STRICT ohne Warning und Error aber mit Noti=
ce.
- Je nach Einzelfall kann es Sinn machen weiterhin PHP 4 Code=20
einzusetzen bis dieser durch PHP 5 Code ersetzt ist. =20
- PHP 4 ist Geschichte -> http://www.gophp5.org/
- PEAR2 setzt PHP 5 voraus
- Alternativen zu PEAR setzen PHP 5 bereits voraus und nutzen die
Möglichkeiten von PHP 5 schon sei längeren.
Dafür muss sich sich doch wirklich nicht endlos lange im Kreis
drehen. =20
tschuess
[|8:)
Sven Drieling wrote:
> - Hinreichend gut programmierte oder aktualisierte PEAR-Pakete laufen
> unter PHP 5 bei E_ALL | E_STRICT ohne Warning und Error aber mit Notice.
Und sind trotzdem PHP4. Nur das ist der Stein des Anstoßes
> - Je nach Einzelfall kann es Sinn machen weiterhin PHP 4 Code
> einzusetzen bis dieser durch PHP 5 Code ersetzt ist.
Klar wer das braucht soll ja nicht unterdrückt werden.
> - PHP 4 ist Geschichte -> http://www.gophp5.org/
ACK
> - PEAR2 setzt PHP 5 voraus
PHP5.3 welches noch nicht releast ist. Also ist PEAR2 Zukunft. Also will
man kein PEAR mehr nutzen wenn man die Wahl hat. Darum gings doch im OP.
> - Alternativen zu PEAR setzen PHP 5 bereits voraus und nutzen die
> Möglichkeiten von PHP 5 schon sei längeren.
Was ein wichtiger Vorteil ist.
> Dafür muss sich sich doch wirklich nicht endlos lange im Kreis
> drehen.
Sollst Du das denn? :-)
MfG, Ulf
Am 14. April 2008 schrieb Ulf Kadner:
> Mark Wiesemann wrote:
>>> d) bei mir. Pear würde ich sowieso keinen empfehlen, da nur PHP4.
>>
>> *gähn*, auch durch Wiederholung wird das nicht richtig.
>
> Ja? Ganz schön grossen Mund für das wenige dahinter. Nur weil da
> neuerdings vieleicht nen paar Packete PHP5 sind (welche sind das bitte?)
> ists im Endeffekt immernoch abhängig von PHP4. (compiliance_mode mal
> aussen vor gelassen)
Ich werde dir sicherlich keine Paketnamen aufschreiben, aber alle
neueren (mind. seit Jahresbeginn) Pakete sind nun mal in PHP 5
geschrieben und sind natürlich nicht abhängig von PHP 4 (statt der
PEAR_Error-Klasse gibt es jetzt eine PEAR_Exception-Klasse).
Natürlich sind die PHP 5-Pakete noch eine Minderheit, aber es werden
laufend mehr Pakete. "nur PHP4" ist und bleibt falsch.
> Ich hab ausserdem bisher noch kein PHP5 Packet für PEAR gesehen.
Was soll ein "PHP5 Packet für PEAR" sein?
Gruß
Mark
--
Egidius Braun: "Der Lothar kann den Fußball gut rüberbringen. Ihm ist
von Gott die Gabe der Rede gegeben worden."
Christoph Herrmann schrieb:
> Hilmar Bunjes schrieb:
>> Oh, sorry. Ich hatte bei deiner Antwort verstanden, dass du mit deiner
>> Kapselung herstellerunabhängig und nicht DAL-unabhängig sein wolltest.
>
> Durch die Kapselung lasse ich mir die Möglichkeit offen andere
> Datenbanken zu unterstützen, die von PDO nicht unterstützt werden
> bisher. PDO lässt sich dahingehend (soweit mir bekannt) ja nicht über
> neue PHP Klassen erweitern, was mich dann wieder abhängig davon machen
> würde, was PDO mir bietet.
Du kannst dafür neue Klassen in C schreiben und sie in PHP
einkompilieren. Oder jemanden damit beauftragen.
> Außerdem mag ich noch paar wichtige Dinge haben, die PDO nicht kann wie
> über die Connection die Liste aller Tabellen der Datenbank holen
Dafür gibt es die Schema Informationen deiner Datenbank. Das hat mit
einem DAL nichts zu tun.
> von einem Resultset einfach die erste Zelle (schön für count(*) Sachen)
PDOStatement::fetch ?
> bzw. allgemein die Trennung Prepared Statement und Resultset.
Das verstehe ich allerdings nicht.
Gruß,
Torsten
Torsten Zühlsdorff schrieb:
> Du kannst dafür neue Klassen in C schreiben und sie in PHP
> einkompilieren. Oder jemanden damit beauftragen.
Lässt sich dann auch auf jedem Webspace einfach so durchführen? ;) Dass
sich PDO in der Hinsicht erweitern lässt weiß ich, allerdings braucht
man dann wesentlich mehr Rechte auf dem Server um dies auch einzubauen.
> Dafür gibt es die Schema Informationen deiner Datenbank. Das hat mit
> einem DAL nichts zu tun.
Die es nicht in jeder Datenbank gibt soweit ich mitbekommen hatte. :)
>> von einem Resultset einfach die erste Zelle (schön für count(*) Sachen)
>
> PDOStatement::fetch ?
"fetch()" gibt die ganze Zeile zurück, mich interessiert aber sehr oft
nur die erste Zelle (also der Wert der ersten Spalte in der ersten
Zeile. Aber stimmt, dafür könnte man "fetchColumn(0)" nehmen, was ich
gestern erfahren hatte hier.
>> bzw. allgemein die Trennung Prepared Statement und Resultset.
>
> Das verstehe ich allerdings nicht.
Ich finde es schlecht, dass wenn ich ein Statement per "query"
durchführe ich ein Objekt der Statement Klasse bekomme. Die Klasse ist
somit zum einen zum vorbereiten und ausführen von Prepared Statements
zuständig und zum Anderen beinhaltet diese das Resultset. Vielleicht
gibt es dafür auch einen logischen Grund, aber ich mag dieses vermischte
nicht.
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Christoph Herrmann schrieb:
>> Du kannst dafür neue Klassen in C schreiben und sie in PHP
>> einkompilieren. Oder jemanden damit beauftragen.
>
> Lässt sich dann auch auf jedem Webspace einfach so durchführen? ;) Dass
> sich PDO in der Hinsicht erweitern lässt weiß ich, allerdings braucht
> man dann wesentlich mehr Rechte auf dem Server um dies auch einzubauen.
Das ist keine ernstzunehmende Ausrede, sobald man die Programmierung
beruflich treibt. Wenn es Sicherheitsbedenken gibt - das wäre ein
Argument. Aber damit zu begründen, dass PDO nicht erweiterbar wäre, ist
absurd. Es ist erweiterbar - aber die Erweiterung lassen sich nicht
immer und überall verwenden.
>> Dafür gibt es die Schema Informationen deiner Datenbank. Das hat mit
>> einem DAL nichts zu tun.
>
> Die es nicht in jeder Datenbank gibt soweit ich mitbekommen hatte. :)
Die Unfähigkeiten von DBs solltest du nicht Applikationen anlasten, die
damit arbeiten (müssen) ;)
>>> bzw. allgemein die Trennung Prepared Statement und Resultset.
>>
>> Das verstehe ich allerdings nicht.
>
> Ich finde es schlecht, dass wenn ich ein Statement per "query"
> durchführe ich ein Objekt der Statement Klasse bekomme. Die Klasse ist
> somit zum einen zum vorbereiten und ausführen von Prepared Statements
> zuständig und zum Anderen beinhaltet diese das Resultset. Vielleicht
> gibt es dafür auch einen logischen Grund, aber ich mag dieses vermischte
> nicht.
Ich persönlich finde die Lösung nicht schlecht. So sind Query und das
dazugehörige ResultSet logisch verbunden. Das scheint aber wohl eher
eine Geschmacksfrage zu sein.
Gruß,
Torsten
Torsten Zühlsdorff schrieb:
> Das ist keine ernstzunehmende Ausrede, sobald man die Programmierung
> beruflich treibt. Wenn es Sicherheitsbedenken gibt - das wäre ein
> Argument. Aber damit zu begründen, dass PDO nicht erweiterbar wäre, ist
> absurd. Es ist erweiterbar - aber die Erweiterung lassen sich nicht
> immer und überall verwenden.
Es ist für mich sehr wohl eine ernstzunehmende Ausrede, da ich nur über
einen Webspace verfüge und diese Rechte nicht besitze. Ich hab auch
nicht behauptet, dass es nicht erweiterbar ist, nur dass es sich nicht
über neue PHP Klassen erweitern lässt.
PS: Ich betreibe die PHP Entwicklung nicht beruflich. ;)
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Torsten Zühlsdorff schrieb:
> Du kannst dafür neue Klassen in C schreiben
Seit wann kann man in C Klassen schreiben?
Gruß. Claus
Claus Reibenstein schrieb:
>> Du kannst dafür neue Klassen in C schreiben
>
> Seit wann kann man in C Klassen schreiben?
Da habe ich mich undeutlich ausgedrückt: Du kannst in C Quellcode
verfassen, der kompliert PHP [DAL]-Klassen hinzufügt.
Gruß,
Torsten
Christoph Herrmann schrieb:
>> Das ist keine ernstzunehmende Ausrede, sobald man die Programmierung
>> beruflich treibt. Wenn es Sicherheitsbedenken gibt - das wäre ein
>> Argument. Aber damit zu begründen, dass PDO nicht erweiterbar wäre,
>> ist absurd. Es ist erweiterbar - aber die Erweiterung lassen sich
>> nicht immer und überall verwenden.
>
> Es ist für mich sehr wohl eine ernstzunehmende Ausrede, da ich nur über
> einen Webspace verfüge und diese Rechte nicht besitze.
Mein Beileid ;)
> Ich hab auch
> nicht behauptet, dass es nicht erweiterbar ist, nur dass es sich nicht
> über neue PHP Klassen erweitern lässt.
Stimmt - das sagtest du. Die Aussage stimmt aber nicht. Es gibt
fsockopen().
Gruß,
Torsten
Torsten Zühlsdorff schrieb:
>> Es ist für mich sehr wohl eine ernstzunehmende Ausrede, da ich nur
>> über einen Webspace verfüge und diese Rechte nicht besitze.
>
> Mein Beileid ;)
Hat aber weniger damit zu tun, dass ich nicht die Voraussetzungen habe
als viel mehr meiner Einstellung, dass man seine Software portierbar
halten sollte, wenn man schon eine portierbare Sprache einsetzt.
Lieber Kapsel ich PDO anstatt mir diese Freiheit zu nehmen und immer an
die entsprechende Rechte gebunden zu sein. Zählt ja mit zu den Stärken
von PHP also warum sollte ich mir diese zunichte machen. ;)
> Stimmt - das sagtest du. Die Aussage stimmt aber nicht. Es gibt
> fsockopen().
Mit der Aussage kann ich nichts anfangen, was natürlich auch daran
liegen könnte, dass ich noch nicht versucht habe (und es auch ohne
nötigen Grund auch nie versuchen würde) PDO selbst zu erweitern. Ich
mache mich da doch lieber unabhängig von PDO.
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Christoph Herrmann schrieb:
> Torsten Zühlsdorff schrieb:
>>> Es ist für mich sehr wohl eine ernstzunehmende Ausrede, da ich nur
>>> über einen Webspace verfüge und diese Rechte nicht besitze.
>>
>> Mein Beileid ;)
>
> Hat aber weniger damit zu tun, dass ich nicht die Voraussetzungen habe
> als viel mehr meiner Einstellung, dass man seine Software portierbar
> halten sollte, wenn man schon eine portierbare Sprache einsetzt.
>
> Lieber Kapsel ich PDO anstatt mir diese Freiheit zu nehmen und immer an
> die entsprechende Rechte gebunden zu sein. Zählt ja mit zu den Stärken
> von PHP also warum sollte ich mir diese zunichte machen. ;)
Portierbarkeit ist meiner wirklich absolut rein persönlichen Meinung
nach in diesem Gebrauch einfach absurd. Natürlich besteht die
theoretische Portierbarkeit des PHP-Interpreters - aber auf wie vielen
der 495 Betriebssysteme kann man den PHP-Interpreter wohl portieren? Und
mit welchem Aufwand? Oder sollte man besser fragen: Welche Teile des
Interpreters?
Portierbarkeit in Sprache und Anwendung ist nur sinnvoll, wenn man ihr
Grenzen setzt - z.b. eine Liste der Betriebssysteme, auf die
(theoretisch) portiert werden können soll. Generell ist die Aussage
nicht haltbar - es sei denn, man verwendet eine Metasprache :P Selbst
wenn man es schaffen würde, eine Software so zu striken, dass sie auf
allen bekannte Betriebssystemen läuft: sie würde nicht auf anderer
Hardware laufen (z.b. Lispmaschinen).
Wenn es dir aber nur darum geht, deine Software auf einer üblichen
PHP-Installation zum laufen zu bekommen: Dann darfst du theoretisch
nichts außerhalb des PHP Cores verwenden. Und von dem Übriggebliebenden
nichts, dass sich ausschalten läßt. Und es läßt sich ziemlich viel
ausschalten. Daher muß man irgendwann Ansprüche stellen.
>> Stimmt - das sagtest du. Die Aussage stimmt aber nicht. Es gibt
>> fsockopen().
>
> Mit der Aussage kann ich nichts anfangen, was natürlich auch daran
> liegen könnte, dass ich noch nicht versucht habe (und es auch ohne
> nötigen Grund auch nie versuchen würde) PDO selbst zu erweitern. Ich
> mache mich da doch lieber unabhängig von PDO.
Das hat gar nichts mit PDO zu tun. fsockopen stelle eine Verbindung so
einen anderem Rechner her. Das ist insofern hilfreich, als das die
meisten Datenbanken auf einem anderen Rechner sitzen und auf einen Port
lauschen. Mit fsockopen kannst du dich zu dem anderen Rechner verbinden
und der Datenbank direkt Befehle übergeben. Das ist zwar umständlich,
aber so kannst du jede Datenbank, die dieses wirklich uralte und
einfache Prinzip verfolgt, ansprechen und bist völlig unabhängig von
PDO, den nativen Datenbankfunktionen von PHP oder irgendwelchen
PEAR-Packages und anderen Frameworks. Und das Beste daran: Diese
grundlegenden Netzwerkfunktionen sind nicht deaktivierbarer Bestandteil
des PHP Kerns. Also genau das, was du suchst - obwohl du hoffen wirst,
es nicht gefunden zu haben, solltest du dich damit auseinandersetzten. ;)
Gruß,
Torsten
Torsten Zühlsdorff schrieb:
> [...]
> Wenn es dir aber nur darum geht, deine Software auf einer üblichen
> PHP-Installation zum laufen zu bekommen: Dann darfst du theoretisch
> nichts außerhalb des PHP Cores verwenden. Und von dem Übriggebliebenden
> nichts, dass sich ausschalten läßt. Und es läßt sich ziemlich viel
> ausschalten. Daher muß man irgendwann Ansprüche stellen.
Darum ging es mir. Mir geht es nicht um Dinge, die man möglicherweise
abschalten kann, denn diese kann man in der Regel ebenso einfach
anschalten bzw. bei vielen Anbietern anschalten lassen.
Aber spätestens wenn es darum geht den Interpreter selbst zu Kompilieren
oder Extensions für diesen einzubinden, ist es vorbei mit der
Möglichkeit die Software auf einem Webspace laufen zu lassen. Und wenn
ich mir diese Einschränkung durch eine einfache Kapselung der Klassen
erspart bleibt, sodass ich meine Schnittstelle um andere
Implementierungen alternativ zu PDO erweitern kann, dann tue ich das.
Meine Meinung und ich denke es bedarf keiner weiteren Diskussion. :)
> Das hat gar nichts mit PDO zu tun. fsockopen stelle eine Verbindung so
> einen anderem Rechner her. Das ist insofern hilfreich, als das die
> meisten Datenbanken auf einem anderen Rechner sitzen und auf einen Port
> lauschen. Mit fsockopen kannst du dich zu dem anderen Rechner verbinden
> und der Datenbank direkt Befehle übergeben. Das ist zwar umständlich,
> aber so kannst du jede Datenbank, die dieses wirklich uralte und
> einfache Prinzip verfolgt, ansprechen und bist völlig unabhängig von
> PDO, den nativen Datenbankfunktionen von PHP oder irgendwelchen
> PEAR-Packages und anderen Frameworks. Und das Beste daran: Diese
> grundlegenden Netzwerkfunktionen sind nicht deaktivierbarer Bestandteil
> des PHP Kerns. Also genau das, was du suchst - obwohl du hoffen wirst,
> es nicht gefunden zu haben, solltest du dich damit auseinandersetzten. ;)
Siehst du, also kann man meine Schnittstellen um genau solch eine
Implementierung erweitern, wenn alle anderen Methoden gar nicht mehr
funktionieren oder man nimmt PDO, wenn dies möglich ist oder irgendetwas
anderes und zwar ohne dass sich die Schnittstelle ändert zur Anwendung
hin. Deswegen Kapsel ich es.
Ich benutze PDO aber ich will meine Anwendung nicht komplett umstellen
müssen, falls ich mal kein PDO zur Verfügung habe bzw. es eine andere
Datenbank betrifft die PDO nun mal nicht unterstützt. Einfach neue
Klassen dafür mit den Schnittstellen implementieren und schon weiß die
Anwendung damit umzugehen.
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Hallo
Ich bevorzuge seit kurzem Creole (http://creole.phpdb.org/trac/). Warum?
Weil Propel drauf aufsetzt, was vom Symfony Framework als standardmäÃiges
Objekt Relationales Mapping benutzt wird.
AuÃerdem ist es stark an JDBC angelehnt, also schonmal vertraut.
Das Zend Framework gefiel mir beim zwei Stunden Zend Framework Buch
querlesen nicht sonderlich (besser als Symfony).
Desweitern konnte ich meine bisherige selbstgebaute Datenbankabstraktion
leicht auf Creole umbiegen und so in Ruhe umsteigen.
Kurz gesagt: Propel/Creole gibt mir alles was ich brauche und "fühlt sich
gut an".
Ob andere Datenbankabstraktionen was können wovon ich noch garnicht weiÃ,
dass ich es brauche weià ich nicht, gucke ich mir mal bei Gelegenheit an,
ich denke aber nicht, dass die mir mehr bieten können als die Propel/Creole
Kombination kann.
GruÃ
Elmar
Elmar Athmer schrieb:
> Ob andere Datenbankabstraktionen was können wovon ich noch garnicht weiÃ,
> dass ich es brauche weià ich nicht, gucke ich mir mal bei Gelegenheit an,
> ich denke aber nicht, dass die mir mehr bieten können als die Propel/Creole
> Kombination kann.
Sehr interessante Ansicht. Du kennst den Rest zwar nicht, bist aber
überzeugt, dass er nicht besser ist. DDDBL z.b. abstrahiert neben der DB
auch die Queries und deren Auswertung. Es erzeugt keinen unnötigen Code
wie z.b. deines. Es bietet eine zentrale Stelle für Caching und das
Testen der Queries. Es ist extrem speicherarm: Im Gegensetz zu den
ganzen Objekten, die pro PHP-Instanz Speicher allozieren, benötigt es
nur eine feste Anzahl an Klassen, ganz gleich wieviel Queries
existieren. Jedes ORM hat eine lange Liste an Nachteilen gegenüber DDDBL.
Aber genug der Selbsthuddelei. DDDBL ist schlieÃlich mein DB-Layer. ;)
GruÃ,
Torsten
Christoph Herrmann schrieb:
> [..]
>
> Meine Meinung und ich denke es bedarf keiner weiteren Diskussion. :)
Meiner Meinung nach schon - aber nicht zu diesem Punkt.
Der Grundgedanke der Abstraktion der DB ist gut. Allerdings ist er
meiner Meinung nach nicht gut genug. Denn er abstrahiert nicht die
Queries. Die Portierbarkeit eines DAL ist nutzlos, wenn man tausende von
Queries im Quellcode anpassen muß.
Aus diesem Grund abstrahiert mein DAL auch die Queries. Und sogar deren
Auswertung. Es gibt schlicht keine Queries mehr im Code. Hat desweiteren
den Vorteil, dass man einen zentralen Ansatz für z.b. Caching oder
Unit-Testing hat.
Gruß,
Torsten
Daniela Waranie schrieb:
> welchen Kandidaten würdet Ihr bzgl. Database Abstraction Layer bevorzugen:
> a) Zend Framework
> b) Pear::MDB2
> c) Pear::DB
> d) other
Vielleicht hilft dir der Thread auch weiter:
http://groups.google.com/group/de.comp.lang.php.misc/browse_ thread/thread/fe81eb4dfee39b0/793f185a09be7bdf
("Kleine Umfrage Frameworks", de.comp.lang.php.misc, ab dem 23. Nov '07)
Gruß,
Hilmar
Torsten Zühlsdorff schrieb:
> Meiner Meinung nach schon - aber nicht zu diesem Punkt.
Dann bin ich beruhigt, andere Punkte sehr gerne, beim Anderen hätten wir
uns wohl ohne Ergebnis weiter hineingesteigert. :)
> Der Grundgedanke der Abstraktion der DB ist gut. Allerdings ist er
> meiner Meinung nach nicht gut genug. Denn er abstrahiert nicht die
> Queries. Die Portierbarkeit eines DAL ist nutzlos, wenn man tausende von
> Queries im Quellcode anpassen muß.
Aus diesem Grund wird meistens über den DAL ein OR Mapper gelegt. :)
Beispiel Propel + Creole wird ja gerne gemacht. Nur leider ist die
Komplexität eines OR Mappers in meinen Augen weitaus höher zu den
möglichen Queries, die man damit realisieren kann. Der Großteil der SQL
Syntax die man häufig braucht ist ja unabhängig vom Datenbanksystem und
ist somit sowieso portierbar.
Ich hab mit Propel und Creole noch nie richtig angeschaut, aber was ich
bereits gesehen habe ist die Einrichtung sehr komplex und ich sehe noch
keinen wirklichen Vorteil darin wirklich alle Queries damit abdecken zu
müssen. Für schnellen Zugriff auf einzelne Datensätze einer Tabelle hab
ich einen eigenen einfachen OR Mapper. Aber vielleicht irre ich mich da
und es ist ganz einfach mit den beiden Bibliotheken zu realisieren. :)
> Aus diesem Grund abstrahiert mein DAL auch die Queries. Und sogar deren
> Auswertung. Es gibt schlicht keine Queries mehr im Code. Hat desweiteren
> den Vorteil, dass man einen zentralen Ansatz für z.b. Caching oder
> Unit-Testing hat.
Also hast du einen eigenen OR Mapper?
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Torsten Zühlsdorff schrieb:
> Aber genug der Selbsthuddelei. DDDBL ist schlieÃlich mein DB-Layer. ;)
Das beantwortet meine Frage aus dem anderen Zweig. :) Gibt es diese
DB-Layer zu sehen? Würde mich doch mal interessieren, wenn es deiner
Meinung nach soviel Vorteile bietet. ;)
--
Mit freundlichen GrüÃen,
Christoph Herrmann
http://dragonprojects.de/
Hallo Elmar,
wo finde ich Einsteiger-Infos zu:
- Creole
- Propel
- DDDBL
?
Lieben Gruß
Daniela Waranie
Daniela Waranie schrieb:
> wo finde ich Einsteiger-Infos zu:
> - Creole
> - Propel
Allgemein zu beiden hilfreich:
http://professionelle-softwareentwicklung-mit-php5.de/db.htm l
Propel:
http://propel.phpdb.org/trac/
Creole:
http://creole.phpdb.org/trac/
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Hey
> Sehr interessante Ansicht. Du kennst den Rest zwar nicht, bist aber
> überzeugt, dass er nicht besser ist. DDDBL z.b. abstrahiert neben der DB
Das habe ich so doch überhaupt nicht gesagt, vor allem nicht, dass "der
Rest" schlechter ist. Sondern ich habe sogar explizit gesagt, dass ich
NICHT weiÃ, ob andere eventuell besser sind (bzw, was können was creole
nicht kann).
AuÃerdem habe ich nichts von Ãberzeugung gesagt, sondern sehr persönlich
meine Gründe dargelegt, warum ICH Creole einsetze.
> existieren. Jedes ORM hat eine lange Liste an Nachteilen gegenüber DDDBL.
Man kann doch kein ORM mit Abstraktionslayern vergleichen, und ob man
nun "nur" ein Layer braucht oder ein komplettes ORM oben drauf ist
natürlich eine Frage des Projektes, vielleicht auch des persönlichen
Geschmackes. In meinem aktuellen Projekt ist die Performance eher
nebensächlich, und die Code Wartbarkeit und Erweiterbarkeit erheblich
wichtiger, deshalb ist der Overhead MIR in DIESEM Fall egal.
Ich habe das extra vorsichtig und auf mich bezogen geschrieben, eben weil
ich mit keinen anderen PHP Abstraktionslayern ernsthafte Erfahrung habe.
Also dreh mir bitte nicht das Wort im Mund komplett um.
Von DDDBL habe ich noch nie etwas gehört, hast du einen Link? Der erste
Googletreffer weist direkt auf dein Posting.
Wie ich schrieb, ich werde mir bei Gelegenheit noch andere Techniken
angucken, da ich eben NICHT überzeugt bin dass das von mir aktuell
eingesetzte unbedingt der Weisheit letzter Schluss ist.
GruÃ
Elmar
Hi
Zu den Links von Christoph noch:
http://www.symfony-project.org/book/1_0/08-Inside-the-Model- Layer
Da ist es halt Symfony bezogen beschrieben. Bis auf das Schema per YAML
sollte es meine ich aber auch generell gelten.
GruÃ
Elmar
Elmar Athmer schrieb:
> Kurz gesagt: Propel/Creole gibt mir alles was ich brauche und "fühlt sich
> gut an".
Habe es mir auch kurz schon angeschaut, aber soweit ich sehe werden
Teile von PEAR benötigt bzw. die beiden sind selbst Bestandteil und
abhängig von PEAR, sehe ich das richtig?
--
Mit freundlichen GrüÃen,
Christoph Herrmann
http://dragonprojects.de/
Hi
Also wie ich http://creole.phpdb.org/trac/wiki/Documentation/Installation
und http://propel.phpdb.org/trac/wiki/Users/Documentation/1.3/In stallation
auf die schnelle verstehe sind die von keinen anderen PEAR Paketen
abhängig. Es gibt die aber der Bequemlichkeit halber auch einfach per PEAR,
ja.
GruÃ
Elmar
Christoph Herrmann schrieb:
>> Meiner Meinung nach schon - aber nicht zu diesem Punkt.
>
> Dann bin ich beruhigt, andere Punkte sehr gerne, beim Anderen hätten wir
> uns wohl ohne Ergebnis weiter hineingesteigert. :)
Vermutlich. Aber wenn man das vorher weiÃ, kann man seine Zeit ja besser
nutzen ;)
>> Der Grundgedanke der Abstraktion der DB ist gut. Allerdings ist er
>> meiner Meinung nach nicht gut genug. Denn er abstrahiert nicht die
>> Queries. Die Portierbarkeit eines DAL ist nutzlos, wenn man tausende
>> von Queries im Quellcode anpassen muÃ.
>
> Aus diesem Grund wird meistens über den DAL ein OR Mapper gelegt. :)
> Beispiel Propel + Creole wird ja gerne gemacht. Nur leider ist die
> Komplexität eines OR Mappers in meinen Augen weitaus höher zu den
> möglichen Queries, die man damit realisieren kann. Der GroÃteil der SQL
> Syntax die man häufig braucht ist ja unabhängig vom Datenbanksystem und
> ist somit sowieso portierbar.
Also nachdem ich mir Propel + Creole angeschaut habe, bin ich eher
entsetzt, dass man soetwas als Fortschritt sieht. Die Abstraktion der
Queries schlägt sich direkt in den Code nieder - jeder komplexer ein
Querie, desto komplexer der Code.
AuÃerdem ist zwar die Syntax der meisten SQL Queries portierbar, aber
die Ausführung kann enormem Abweichungen unterliegen. Während z.B. ein
SELECT COUNT(*) auf MySQL sofort 100Mio als Antwort zurückgibt, wird man
z.b. in PostGres bis zum Ende des Seq-Scans warten müssen, um das
Ergebnis zu erhalten.
>> Aus diesem Grund abstrahiert mein DAL auch die Queries. Und sogar
>> deren Auswertung. Es gibt schlicht keine Queries mehr im Code. Hat
>> desweiteren den Vorteil, dass man einen zentralen Ansatz für z.b.
>> Caching oder Unit-Testing hat.
>
> Also hast du einen eigenen OR Mapper?
Jein. DDDBL ist kein OR-Mapper. ORM ist meiner Meinung nach ein
Designfehler. ;) Es erzeugt unnötigt Code und damit Komplexibilität
(verbunden mit Kosten in Wartung, Testing usw.). ORMs benötigen zuviel
Speicher und erschweren das Testen.
DDDBL heiÃt "Definition Driven Database Layer". SQL Queries stehen einer
Syntax folgend in Textdateien und werden für einen bestimmten DB-Typ
gebunden. Der Layer ermöglicht die gleichzeitige Verwendung von einer
beliebigen Anzahl an Datenbanken mit verschiedenen Datenbanktypen (also
zeitlgeich Oracle, PostGres, MySQL usw.).
Die Queries werden mit einem Alias versehen, so dass der Quellcode auf
einen 2-Zeiler reduziert wird. Eine Zeile stellt eine Verbindung zur
gewünschten DB her, die zweite führt den gewünschten Query aus. Der Code
sieht dann so aus:
$objDB = new DDDBL('datenbank-alias');
$objDB->get('QUERY-ALIAS', optionale-n-parameter);
Falls nur eine DB verwendet wird, kann man das auch auf eine Zeile
reduzieren ;)
Selbst wenn sich die Datenbankstruktur grundlegend ändern sollte: Man
paÃt den Query in der Textdatei an. Auf den Code hat es keine
Auswirkung. Bei ORM hingegen müÃte man hunderte Zeilen Code refactorieren.
Die üblichen Vorgänge wie z.b. eine Ressource holen, sie auswerten und
die Ergebnisse in einem beliebig formatierten Array schreiben, entfallen
in den Standardausführungen, weil der Layer das bereits übernimmt. Die
zweite Zeile bringt also bereits das vollständige Ergebnis im richtigen
Format zurück.
Auch übliche Standardfälle wie z.b. das holen eines Datensatzes nur um
herauszufinden, ob er existiert können einfach durch einen sogenannten
"Handler" ohne weitere Arbeit abgefangen werden.
Durch den zentrale Struktur kann man natürlich an zentraler Stelle
CachingâMechanismen hinterlegen oder das ganze in eine Teststruktur
einbinden, um die Queries automatisiert zu testen. Beides ist aber noch
kein Standard-Bestandteil.
Um auf die Frage aus dem anderen Post zu antworten: Ja, du kannst ihn
gerne haben. Er soll unter www.dddbl.de mit BSD-Lizenz angeboten werden.
Aber ohne Dokumentation gebe ich das nur sehr ungern raus. ;) Der
Ersteindruck sollte nicht "Verwirrung" sein. Wenn du aber darauf
bestehst, kannst du ihn gerne haben.
GruÃ,
Torsten
Elmar Athmer schrieb:
>> existieren. Jedes ORM hat eine lange Liste an Nachteilen gegenüber DDDBL.
>
> Man kann doch kein ORM mit Abstraktionslayern vergleichen, und ob man
> nun "nur" ein Layer braucht oder ein komplettes ORM oben drauf ist
> natürlich eine Frage des Projektes, vielleicht auch des persönlichen
> Geschmackes.
Meiner Meinung nach schon: Ein ORM ist auch nur ein Abstraktionslayer
mit dem Ziel, DB und Queries zu abstrahieren. DDDBL macht genau das
selbe - nur völlig anders.
> Also dreh mir bitte nicht das Wort im Mund komplett um.
Entschuldigung - da habe ich deine Implikation völlig falsch verstanden.
> Von DDDBL habe ich noch nie etwas gehört, hast du einen Link? Der erste
> Googletreffer weist direkt auf dein Posting.
Da ist Google aber schnell. Wie erwähnt ist DDDBL mein persönlicher
Layer, der sich gerade in einigen Projekten behaupten muÃ. Bevor er
nicht absolut sicher und in der Anwendung dokumentiert ist, wird er
natürlich nicht veröffentlich.
> Wie ich schrieb, ich werde mir bei Gelegenheit noch andere Techniken
> angucken, da ich eben NICHT überzeugt bin dass das von mir aktuell
> eingesetzte unbedingt der Weisheit letzter Schluss ist.
Dann schaue mal in einiger Zeit auf www.dddbl.de nach.
GruÃ,
Torsten
Torsten Zühlsdorff schrieb:
> Also nachdem ich mir Propel + Creole angeschaut habe, bin ich eher
> entsetzt, dass man soetwas als Fortschritt sieht. Die Abstraktion der
> Queries schlägt sich direkt in den Code nieder - jeder komplexer ein
> Querie, desto komplexer der Code.
Das ist für mich noch der gröÃte Störfaktor. Es wird einfach ungemein
komplex, wenn man sämtliche SQL Queries abzubilden versucht. Vor allem
bei Propel die Datenbankstruktur in XML abbilden, daraus per Generator
PHP Klassen erzeugen in meinen Augen grässlich... Kann ich mich
zumindest nicht mit anfreunden. :)
> Jein. DDDBL ist kein OR-Mapper. ORM ist meiner Meinung nach ein
> Designfehler. ;) Es erzeugt unnötigt Code und damit Komplexibilität
> (verbunden mit Kosten in Wartung, Testing usw.). ORMs benötigen zuviel
> Speicher und erschweren das Testen.
Ich hab nur einen kleinen ORM, der vor allem die Einschränkung besitzt,
dass er nur einzelne Datensätze einer Tabelle laden und manipulieren
kann anhand der Primärschlüssel.
Folglich sieht es bei zum Beispiel so aus:
//Benutzerobjekt mit der ID 1 erstellen
$member = new Member(1);
//Die angegebenen Spalten des Datensatzes laden
$member->load(array('username', 'email'));
//Beliebig die Daten ausgeben
print $member->getData('username');
//Oder auch ändern
$member->setData('email', 'neu@email.de');
//Ãnderungen speichern
$member->update();
Ich finde das Ganze sehr viel einfacher auf der Ebene als ein komplexer
ORM und auf jeden Fall erspar ich mir damit sehr viele kleine Queries.
Aufgebaut ist das Ganze durch eine abstrakte Klasse von ca. 200 Zeilen
Quellcode und pro Tabelle dann eine abgeleitete Klasse, die lediglich
die Primärschlüssel definiert und Besonderheiten implementiert (bei der
Benutzerklasse zum Beispiel eine Methode zur Registrierung). Ich finde
das sehr bequem und auch effizient.
Der gröÃte Vorteil für mich stellt aber vor allem das Benutzerobjekt dar
des aktuell eingeloggten Benutzers. Es wird einmal erstellt beim ersten
Aufruf der Seite und in die Session gelegt. Zwischendurch wird der
Datensatz beim Login geladen. Danach kann dieser verändert werden und
wird am Ende der Seite automatisch gespeichert. Daher egal an wie vielen
Stellen ich Daten des aktuellen Benutzers ändere, es wird nur einmal
gespeichert und ich habe über das Objekt einfachen Zugriff ohne dauernd
Daten selektieren zu müssen.
> [...]
> Um auf die Frage aus dem anderen Post zu antworten: Ja, du kannst ihn
> gerne haben. Er soll unter www.dddbl.de mit BSD-Lizenz angeboten werden.
> Aber ohne Dokumentation gebe ich das nur sehr ungern raus. ;) Der
> Ersteindruck sollte nicht "Verwirrung" sein. Wenn du aber darauf
> bestehst, kannst du ihn gerne haben.
Hört sich auf jeden Fall gut durchdacht an und ich würde mir das gerne
anschauen. Vielleicht lassen sich unsere beiden Konzepte verbinden, denn
mein ORM hat ganz klar Grenzen und man kommt damit nicht um Queries
herum. Die einfachen Queries kann man sich bei mir bequem ersparen, aber
für alles komplexere gefällt mir dein Konzept recht gut.
Die Homepage scheint noch nicht online zu sein? Darfst mir aber gern
nähere Informationen per PM zusenden. ;)
--
Mit freundlichen GrüÃen,
Christoph Herrmann
http://dragonprojects.de/
Christoph Herrmann schrieb:
> Torsten Zühlsdorff schrieb:
>> Also nachdem ich mir Propel + Creole angeschaut habe, bin ich eher
>> entsetzt, dass man soetwas als Fortschritt sieht. Die Abstraktion der
>> Queries schlägt sich direkt in den Code nieder - jeder komplexer ein
>> Querie, desto komplexer der Code.
>
> Das ist für mich noch der gröÃte Störfaktor. Es wird einfach ungemein
> komplex, wenn man sämtliche SQL Queries abzubilden versucht. Vor allem
> bei Propel die Datenbankstruktur in XML abbilden, daraus per Generator
> PHP Klassen erzeugen in meinen Augen grässlich... Kann ich mich
> zumindest nicht mit anfreunden. :)
Geht mir genauso.
>> Jein. DDDBL ist kein OR-Mapper. ORM ist meiner Meinung nach ein
>> Designfehler. ;) Es erzeugt unnötigt Code und damit Komplexibilität
>> (verbunden mit Kosten in Wartung, Testing usw.). ORMs benötigen zuviel
>> Speicher und erschweren das Testen.
>
> Ich hab nur einen kleinen ORM, der vor allem die Einschränkung besitzt,
> dass er nur einzelne Datensätze einer Tabelle laden und manipulieren
> kann anhand der Primärschlüssel.
>
> Folglich sieht es bei zum Beispiel so aus:
>
> //Benutzerobjekt mit der ID 1 erstellen
> $member = new Member(1);
>
> //Die angegebenen Spalten des Datensatzes laden
> $member->load(array('username', 'email'));
>
> //Beliebig die Daten ausgeben
> print $member->getData('username');
>
> //Oder auch ändern
> $member->setData('email', 'neu@email.de');
>
> //Ãnderungen speichern
> $member->update();
>
> Ich finde das Ganze sehr viel einfacher auf der Ebene als ein komplexer
> ORM und auf jeden Fall erspar ich mir damit sehr viele kleine Queries.
Diese Ersparnis gibt es bei mir nicht - anderseits ist die Syntax so
erschreckend einfach, dass man die Queries auch mit wenig Aufwand
schlicht generieren kann.
>> Um auf die Frage aus dem anderen Post zu antworten: Ja, du kannst ihn
>> gerne haben. Er soll unter www.dddbl.de mit BSD-Lizenz angeboten
>> werden. Aber ohne Dokumentation gebe ich das nur sehr ungern raus. ;)
>> Der Ersteindruck sollte nicht "Verwirrung" sein. Wenn du aber darauf
>> bestehst, kannst du ihn gerne haben.
>
> Hört sich auf jeden Fall gut durchdacht an und ich würde mir das gerne
> anschauen. Vielleicht lassen sich unsere beiden Konzepte verbinden, denn
> mein ORM hat ganz klar Grenzen und man kommt damit nicht um Queries
> herum. Die einfachen Queries kann man sich bei mir bequem ersparen, aber
> für alles komplexere gefällt mir dein Konzept recht gut.
Ich denke, dass sollte tatsächlich klappen können.
> Die Homepage scheint noch nicht online zu sein? Darfst mir aber gern
> nähere Informationen per PM zusenden. ;)
Das ist richtig. Ich habe sie auch erst vor kurzem registiert. Ich würde
vorschlagen, dass ich in den nächsten Tagen mal eine Version auf der HP
hinterlege und immerhin eine grobe Anwendungsdoku dazuschreibe. Dann
kannst du es dir gerne anschauen.
Der Code selbst ist zwar durchgängig dokumentiert und einfach gehalten -
das Prinzip dahinter ist aber wenig trivial ;) Ich gebe dir dann einfach
nächste Woche bescheid.
GruÃ,
Torsten
Torsten Zühlsdorff schrieb:
> Diese Ersparnis gibt es bei mir nicht - anderseits ist die Syntax so
> erschreckend einfach, dass man die Queries auch mit wenig Aufwand
> schlicht generieren kann.
Genau das mach ich doch? :) Gerade weil die Syntax solcher Queries sehr
einfach ist ist der ORM bei mir sehr überschaubar und deckt einen
GroÃteil der benötigten Queries ab. Ansonsten bräuchte ich ja für jede
Tabelle mehrere solcher einfachen Queries, was ich dann schon wieder
unübersichtlich und vor allem unnötig finde.
> Das ist richtig. Ich habe sie auch erst vor kurzem registiert. Ich würde
> vorschlagen, dass ich in den nächsten Tagen mal eine Version auf der HP
> hinterlege und immerhin eine grobe Anwendungsdoku dazuschreibe. Dann
> kannst du es dir gerne anschauen.
> Der Code selbst ist zwar durchgängig dokumentiert und einfach gehalten -
> das Prinzip dahinter ist aber wenig trivial ;) Ich gebe dir dann einfach
> nächste Woche bescheid.
Sehr gern, da ich momentan wegen Abschlussprüfungen eh noch nicht dazu
kommen werde bei meinen privaten Projekten weiter zu machen hab ich es
auch nicht eilig derzeit. :)
--
Mit freundlichen GrüÃen,
Christoph Herrmann
http://dragonprojects.de/
Christoph Herrmann
>Ich hab nur einen kleinen ORM, der vor allem die Einschränkung besitzt,
>dass er nur einzelne Datensätze einer Tabelle laden und manipulieren
>kann anhand der Primärschlüssel.
Das heißt, wenn es keinen Primärschlüssel gibt, möglicherweise auch in
Fällen zusammengesetzter Primärschlüssel, musst Du Dir die Daten auf
eine andere Art holen.
>Folglich sieht es bei zum Beispiel so aus:
>
>//Benutzerobjekt mit der ID 1 erstellen
>$member = new Member(1);
>
>//Die angegebenen Spalten des Datensatzes laden
>$member->load(array('username', 'email'));
>
>//Beliebig die Daten ausgeben
>print $member->getData('username');
>
>//Oder auch ändern
>$member->setData('email', 'neu@email.de');
>
>//Änderungen speichern
>$member->update();
Benutzt Du den Konstruktor, um ein neues Objekt zu erstellen oder um
eines anhand von Daten aus der Datenbank zu laden? Ich kann dazu
raten, in solchen Fällen den Konstruktor privat zu deklarieren, um
explizit zu machen, ob das Objekt aus der Datenbank geholt oder neu
erstellt werden soll. Also static create() und static load() mit
private __construct().
>Ich finde das Ganze sehr viel einfacher auf der Ebene als ein komplexer
>ORM und auf jeden Fall erspar ich mir damit sehr viele kleine Queries.
>Aufgebaut ist das Ganze durch eine abstrakte Klasse von ca. 200 Zeilen
>Quellcode und pro Tabelle dann eine abgeleitete Klasse, die lediglich
>die Primärschlüssel definiert und Besonderheiten implementiert (bei der
>Benutzerklasse zum Beispiel eine Methode zur Registrierung). Ich finde
>das sehr bequem und auch effizient.
Was ist mit Tabellen, welche nicht in Objekten repräsentiert werden
(können)? Was ist mit 1/n-zu-n-Beziehungen?
>Der größte Vorteil für mich stellt aber vor allem das Benutzerobjekt dar
>des aktuell eingeloggten Benutzers. Es wird einmal erstellt beim ersten
>Aufruf der Seite und in die Session gelegt. Zwischendurch wird der
>Datensatz beim Login geladen. Danach kann dieser verändert werden und
>wird am Ende der Seite automatisch gespeichert. Daher egal an wie vielen
>Stellen ich Daten des aktuellen Benutzers ändere, es wird nur einmal
>gespeichert und ich habe über das Objekt einfachen Zugriff ohne dauernd
>Daten selektieren zu müssen.
Du speicherst immer beim Aufruf einer Seite, unabhängig davon, ob sich
etwas geändert hat. Würdest Du das auch machen, wenn Du wüsstest, dass
sich die Daten des Benutzerobjekts üblicherweise nicht ändern?
Dein "kleiner ORM" ist zwar einfach, aber auch unbenutzbar ;-)
Schöne Grüße, Steffen
--
Das Tastaturlayout für Programmierer:
http://eurkey.steffen.bruentjen.eu
steffen bruentjen schrieb:
> Das heißt, wenn es keinen Primärschlüssel gibt, möglicherweise auch in
> Fällen zusammengesetzter Primärschlüssel, musst Du Dir die Daten auf
> eine andere Art holen.
Jede Tabelle sollte einen Primärschlüssel haben, wie sonst könnte man
einzelne Datensätze bearbeiten. Zusammengesetzte Primärschlüssel sind
aber kein Problem, gibt es halt mehrere und es müssen immer alle dem
Konstruktor übergeben werden.
Aber ganz im Notfall oder unabhängig des Primärschlüssels gibt es eine
Methode, mit welcher Primärschlüssel definieren kannst für das
derzeitige Objekt, so kannst einen Benutzer zum Beispiel auch über
seinen Namen laden:
$member = new Member();
$member->setPrimaryKey('username', 'Benutzer');
$member->load(...);
Dafür sollte die Spalte "username" halt sicherheitshalber als Unique
definiert sein. Mein ORM schreibt ganz klar vor: Es wird nur der erste
Datensatz geladen der unter dem Schlüssel gefunden wird und nur dieser
kann bearbeitet werden.
Die Selektion/Manipulation mehrere Datensätze oder über mehrere Tabellen
wird bei mir nach wie vor über SQL gemacht, weil ich keinen Sinn darin
sehe SQL komplett nachzubilden und meine Klassen nur unnötig kompliziert
zu machen.
> Benutzt Du den Konstruktor, um ein neues Objekt zu erstellen oder um
> eines anhand von Daten aus der Datenbank zu laden? Ich kann dazu
> raten, in solchen Fällen den Konstruktor privat zu deklarieren, um
> explizit zu machen, ob das Objekt aus der Datenbank geholt oder neu
> erstellt werden soll. Also static create() und static load() mit
> private __construct().
Über den Konstruktor wird ein neues Objekt erstellt und es können die
Angaben der Primärschlüssel übergeben werden. Geladen wird der Datensatz
nur über den Aufruf der Methode "load()", hier wird auch festgelegt,
welche Spalten geladen werden (oder * wenn nichts übergeben wird).
Man kann auch genauso gut ein Objekt erstellen ohne dass Daten geladen
werden um etwa einen neuen Datensatz zu definieren und einzufügen:
$member = new Member();
$member->setData('username', 'Benutzer');
$member->insert();
Daher hätte es keinerlei Sinn den Konstruktor privat zu deklarieren.
> Was ist mit Tabellen, welche nicht in Objekten repräsentiert werden
> (können)? Was ist mit 1/n-zu-n-Beziehungen?
Siehe oben, mein ORM ist nur dafür gedacht um einzelne Datensätze einer
Tabelle zu bearbeiten. Daten über mehrere Tabellen oder mehrere
Datensätze werden nicht abgedeckt, das würde die Komplexität stark
anheben und ist nicht meine Vorstellung einer Hilfsklasse.
Ich hab nicht das Bedürfnis über den ORM alle Queries abzudecken,
sondern einfach die die man oft braucht um mit einzelnen Objekten ganz
einfach arbeiten zu können.
> Du speicherst immer beim Aufruf einer Seite, unabhängig davon, ob sich
> etwas geändert hat. Würdest Du das auch machen, wenn Du wüsstest, dass
> sich die Daten des Benutzerobjekts üblicherweise nicht ändern?
Natürlich nur wenn sich auch etwas geändert hat... :)
> Dein "kleiner ORM" ist zwar einfach, aber auch unbenutzbar ;-)
Wieso unbenutzbar? Für meine Bedürfnisse ist er brauchbar und er erfüllt
seinen Zweck wofür er gedacht ist: einfach mit einzelnen Objekten
arbeiten zu können.
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Christoph Herrmann
>steffen bruentjen schrieb:
>> Das heißt, wenn es keinen Primärschlüssel gibt, möglicherweise auch in
>> Fällen zusammengesetzter Primärschlüssel, musst Du Dir die Daten auf
>> eine andere Art holen.
>
>Jede Tabelle sollte einen Primärschlüssel haben, wie sonst könnte man
>einzelne Datensätze bearbeiten. Zusammengesetzte Primärschlüssel sind
>aber kein Problem, gibt es halt mehrere und es müssen immer alle dem
>Konstruktor übergeben werden.
Bei Assoziationstabellen ist das Fremdschlüsselpaar zwar UNIQUE, aber
nicht PRIMARY. Semantisch wird ein Primärschlüssel verwendet, um einen
Datensatz eindeutig identifizieren zu können. Du beziehst Dich also
vermutlich auf den UNIQUE-Part des Primärschlüssels...
>Die Selektion/Manipulation mehrere Datensätze oder über mehrere Tabellen
>wird bei mir nach wie vor über SQL gemacht, weil ich keinen Sinn darin
>sehe SQL komplett nachzubilden und meine Klassen nur unnötig kompliziert
>zu machen.
....jetzt verstehe ich etwa, was Du meinst. Dein Benutzerobjekt erbt
von Deinem mapper, mit dem einzelne Attribute aus der Datenbank geholt
werden können. Da Du Objekte, welche sich über mehrere Tabellen
erstrecken weiterhin mit SQL lädst, kommen Assoziationstabellen
sowieso nicht vor.
Komplexeren Anfragen laufen dann mit SQL und PDOs FETCH_INTO oder
FETCH_CLASS, wie z.B.
$stmt->setFetchMode(PDO::FETCH_CLASS,
$objects = $stmt->fetchAll();
Vererbst Du alle persistenten Objekte von dem mapper?
>Über den Konstruktor wird ein neues Objekt erstellt und es können die
>Angaben der Primärschlüssel übergeben werden. Geladen wird der Datensatz
>nur über den Aufruf der Methode "load()", hier wird auch festgelegt,
>welche Spalten geladen werden (oder * wenn nichts übergeben wird).
>[...]
>Daher hätte es keinerlei Sinn den Konstruktor privat zu deklarieren.
Ist wohl eine Frage des Geschmacks. Beim Erzeugen des Objekts ist ja
üblicherweise klar, ob es aus der Datenbank kommt oder in die
Datenbank eingefügt wird. Insofern ist meinem Empfinden nach eine
eindeutige Trennung durch create() und load() klarer. Das Objekt ist
beim Erzeugen direkt zuzuordnen. Andernfalls muss man erst im
Folgecode nach load()- oder insert()-Statements suchen.
>> Dein "kleiner ORM" ist zwar einfach, aber auch unbenutzbar ;-)
>
>Wieso unbenutzbar? Für meine Bedürfnisse ist er brauchbar und er erfüllt
>seinen Zweck wofür er gedacht ist: einfach mit einzelnen Objekten
>arbeiten zu können.
Warum willst Du diese "Hilfsklasse" mit dem DDDwiewardas-Layer-Monster
von Torsten verbinden, bei dem Du Dich mit 20 verschiedenerr DBMSs
gleichzeitig verbinden kannst? :-)
Schöne Grüße, Steffen
--
Das Tastaturlayout für Programmierer:
http://eurkey.steffen.bruentjen.eu
Torsten Zühlsdorff
>
>$objDB = new DDDBL('datenbank-alias');
>$objDB->get('QUERY-ALIAS', optionale-n-parameter);
Und bietest Du hier auch typische Methoden wie getAssoc(),
fetchInto(), möglicherweise auch count() etc. an?
Schöne Grüße, Steffen
ps. ach eine antwort zu den Exceptions/CS kommt glaub ich auch noch;
ich wurde damals beim schreiben durch etwas mehrtagiges unterbrochen!
--
Das Tastaturlayout für Programmierer:
http://eurkey.steffen.bruentjen.eu
steffen bruentjen schrieb:
> Bei Assoziationstabellen ist das Fremdschlüsselpaar zwar UNIQUE, aber
> nicht PRIMARY. Semantisch wird ein Primärschlüssel verwendet, um einen
> Datensatz eindeutig identifizieren zu können. Du beziehst Dich also
> vermutlich auf den UNIQUE-Part des Primärschlüssels...
Ja/Nein :) die Klasse der Tabelle selbst definiert den Primärschlüssel
den man über den Konstruktor übergeben kann. Aber im Prinzip lässt sich
jede Spalte benutzen um einen Datensatz zu identifizieren, nur wäre es
halt geschickt, dass die Spalten selbst Unique sind.
> ...jetzt verstehe ich etwa, was Du meinst. Dein Benutzerobjekt erbt
> von Deinem mapper, mit dem einzelne Attribute aus der Datenbank geholt
Hatte ich das nicht erwähnt? Ich hab eine abstrakte Klasse die alles
verwaltet wie das generieren der Statements, das Setzen der Werte etc.
und die einzelnen Tabellenklassen erben davon und definieren nur die
Primärschlüssel und spezielle Methoden die noch benötigt werden wie
Registrierung bei der Benutzerklasse.
> werden können. Da Du Objekte, welche sich über mehrere Tabellen
> erstrecken weiterhin mit SQL lädst, kommen Assoziationstabellen
> sowieso nicht vor.
>
> Komplexeren Anfragen laufen dann mit SQL und PDOs FETCH_INTO oder
> FETCH_CLASS, wie z.B.
>
> $stmt->setFetchMode(PDO::FETCH_CLASS,
> $objects = $stmt->fetchAll();
Ja, alles was über den ORM hinaus geht geschieht weiterhin per SQL.
Einfach weil ich kein Sinn darin sehe den ORM so komplex zu machen, dass
er alles abdecken kann. Dann gehe ich bei den paar komplexeren Sachen,
die man sonst noch braucht über den Weg den Torsten beschrieben hat.
> Vererbst Du alle persistenten Objekte von dem mapper?
Jede Tabelle in der Datenbank wird in der Regel auch von einer Klasse in
PHP repräsentiert, allein schon weil eigentlich alle Inserts über die
Klassen gemacht werden.
> Ist wohl eine Frage des Geschmacks. Beim Erzeugen des Objekts ist ja
> üblicherweise klar, ob es aus der Datenbank kommt oder in die
> Datenbank eingefügt wird. Insofern ist meinem Empfinden nach eine
> eindeutige Trennung durch create() und load() klarer. Das Objekt ist
> beim Erzeugen direkt zuzuordnen. Andernfalls muss man erst im
> Folgecode nach load()- oder insert()-Statements suchen.
Bei mir ist es klar dass bei der Instanzierung lediglich das Objekt in
PHP instanziert und nichts geladen oder gespeichert wird in der
Datenbank. Würde auch kein Sinn machen, da beim Instanzieren gar nicht
klar ist ob ich jetzt ein neues Objekt anlegen will oder einfach nur
eines laden will zum Auslesen und Ausgeben.
> Warum willst Du diese "Hilfsklasse" mit dem DDDwiewardas-Layer-Monster
> von Torsten verbinden, bei dem Du Dich mit 20 verschiedenerr DBMSs
> gleichzeitig verbinden kannst? :-)
Ich hab gesagt mir gefällt das Konzept sehr gut und ich würde es mir
gerne anschauen und die Konzepte miteinander verbinden. Damit meinte ich
nicht die Implementierungen. ;)
Ich hab einen eigenen DAL, wie man in anderen Zweigen dieses Themas
entnehmen kann. :) Mein ORM benutzt diesen dann.
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Christoph Herrmann schrieb:
>> Warum willst Du diese "Hilfsklasse" mit dem DDDwiewardas-Layer-Monster
>> von Torsten verbinden, bei dem Du Dich mit 20 verschiedenerr DBMSs
>> gleichzeitig verbinden kannst? :-)
PS: Mein DAL kann auch eine Connection zu einer beliebigen Tabelle
aufnehmen unter einem eindeutigen Namen hinterlegen. Die Tabellenklasse
holt sich dann die Connection unter diesem Namen.
Daher wäre es möglich transparent zur Anwendung hin jede einzelne
Tabellen in verschiedene Datenbanken verschiedener DBMSs zu verwalten.
Nutze ich zum Beispiel, weil ich Anwendungsbezogene Daten und Logdaten
in verschiedene Datenbanken habe und in verschiedenen Rhythmen sichere.
Lässt sich halt nachträglich nicht mehr so einfach umbiegen so eine
Trennung in verschiedene DBs, spätestens wenn dann SQL Statements
existieren für die komplexere Sachen. ;)
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
steffen bruentjen schrieb:
>> $objDB = new DDDBL('datenbank-alias');
>> $objDB->get('QUERY-ALIAS', optionale-n-parameter);
>
> Und bietest Du hier auch typische Methoden wie getAssoc(),
> fetchInto(), möglicherweise auch count() etc. an?
Nein (eigentlich schon,aber das tut nichts zur Sache). Wie erwähnt wird
die Auswertung automatisiert vorgenommen. Möchtest du eine beliebige
Funktionalität (was auch immer sich hinter dahingeworfenen Methodennamen
verbirgt), schreibe dir eine schlichte Auswertung dafür. Selbst in
großen Projekten sind die gewünschten Ergebnisstrukturen weitläufig ähnlich.
> ps. ach eine antwort zu den Exceptions/CS kommt glaub ich auch noch;
> ich wurde damals beim schreiben durch etwas mehrtagiges unterbrochen!
Wunderbar. Ich habe Zeit, fühle dich nicht gestresst.
Gruß,
Torsten
Christoph Herrmann schrieb:
>>> Warum willst Du diese "Hilfsklasse" mit dem DDDwiewardas-Layer-Monster
>>> von Torsten verbinden, bei dem Du Dich mit 20 verschiedenerr DBMSs
>>> gleichzeitig verbinden kannst? :-)
>
> PS: Mein DAL kann auch eine Connection zu einer beliebigen Tabelle
> aufnehmen unter einem eindeutigen Namen hinterlegen. Die Tabellenklasse
> holt sich dann die Connection unter diesem Namen.
>
> Daher wäre es möglich transparent zur Anwendung hin jede einzelne
> Tabellen in verschiedene Datenbanken verschiedener DBMSs zu verwalten.
> Nutze ich zum Beispiel, weil ich Anwendungsbezogene Daten und Logdaten
> in verschiedene Datenbanken habe und in verschiedenen Rhythmen sichere.
>
> Lässt sich halt nachträglich nicht mehr so einfach umbiegen so eine
> Trennung in verschiedene DBs, spätestens wenn dann SQL Statements
> existieren für die komplexere Sachen. ;)
Doch. Die Statements sind nur Text. Nicht mehr. Einfachste
Metaprogrammierung erfüllt dir auch diesen Wunsch. ;)
Abgesehen davon ist dies auch schlicht und ergreifend nicht der Zweck
vom DDDBL. Dieser besteht nämlich in einer schnellen, einfachen,
speicherarmen und zeitsparenden (!) Verwendung von Datenbanken, mit der
Möglichkeit, Queries, die perfekt auf die Systeme zugeschnitten sind, zu
verwenden. Dazu kommt das Ziel, durch möglichst ohne Unabhängigkeit eine
Portierbarkeit der DB im Rahmen der durch PDO unterstützten DBs zu
ermöglichen.
Das größte Ziel ist aber folgendes: Die Auswirkung der Datenbankstruktur
auf den Quellcode auf 0 zu reduzieren.
Und all das ist mir gelungen ;)
Gruß,
Torsten