Dark Guardian

Sers

Wie ggf. noch aus anderen Themen von mir bekannt entwickel ich grad ein MVC-CMS und bin aktuell dabei das Konzept der Datenbank und ihrer
Abstraktion, zur Verwendung verschiedener DBMS, zusammenzustellen.

Erster Teil des Konzeptes: Alle DBMS unter einen Hut bringen

Dabei ist mir natürlich auch die PHP Erweiterung PDO aufgefallen die im Prinzip das leistet was ich eigentlich haben will. Zwar gehört PDO zwar mittlerweile zur Standarddistribution von PHP, das macht es aber noch längst nicht überall verfügbar. Daher ist meine erste Frage ob ich meine Datenbankklassen vollständig auf PDO stützen sollte oder eher nicht?

Eine zusätzliches Interface und eine Verbindungsklasse für jedes DBMS zu entwickeln, welche dann die DBMS spezifischen Funktionen entsprechend vereinheitlicht wäre weniger das Problem. Zumal dies nur bei Bedarf getan werden mnuss und MySQL (als Standard Implementierung) in den meisten Fällen ausreicht.

Ich stelle mir das in etwa so vor:

(Natürlich ein stark vereinfachtes Beispiel)

Macht das Sinn? Würde ich die PDO verwenden bliebe mir dieser Zusatzaufwand erspart. Nur wäre PDO dann eine (ggf. weitere) Abhängigkeit ohne die mein System nicht lauffähig wäre.

Zweiter Teil: Abnahme von Routineaufgaben

Aus meiner ehemaligen Delphi Zeit ist mir der dortige Datenbankaufbau noch gut geläufig. Dort gibt es die Komponenten TDatabase, TTable und TField. Ich gehe mal davon aus das sich deren Verwendung anhand ihrer Namen selbst erklärt. Zusätzlich gab es die Komponente TDataSet welche über verschiedene Bibliotheken die Verbindung zum entsprechendem DBMS herstellte.

Meine Frage an euch ist nun wie sinnvoll es ist ein ähnliches System in PHP umzusetzen. Als Beispiel nehemn wir eine Klasse Database welcher im Konstruktor ein Objekt übergeben bekommt welches das Interface IDatabaseConnection implementiert. Die Database-Klasse stellt Methoden zur Verfügung wie getTable() über welche man sich für eine bestimmte Tabelle ein DBTableObjekt holen kann um Felder oder Zeilen auszulesen welche durch DBFieldund DBRow Objekte repräsentiert werden.

Dieses Konstrukt soll mir dazu dienen einfache SQL Statements nicht mehr immer vollständig ausformulieren zu müssen sondern von den oben genannten Objekten erzeugen und ausführen zu lassen.

Außerdem bietet es mir die Option z.B. eine Klasse Admin von der Klasse DBRow erben zu lassen und somit nur über die ID eines Admins automatisch in einem Objekt alle relevanten Daten über einen Admin zu erhalten.

DBTable könnte als Elternklasse für z.B. Listen herhalten was mir erlaubt einer View-Klasse sehr simpel alle Datenressourcen für eine Liste zu übergeben. Es reicht 1 Objekt für die komplette Liste aus. Einschränkungen werden in der Kindklasse durch zusätzlich implementierte Methoden vorgenommen womit der Controller nur noch wenige Methodenaufrufe zu erledigen hat anstatt komplexe SQL-Statements zusammenfrickeln zu müssen.

Meine Sorge ist nur das dies ein bisschen zu viel Overhead mit sich bringt da für die meisten Anwendungen eine Klasse welche einzelne Datensätze repräsentiert ausreicht. Klassen zur Repräsentation von Tabellenspalten habe ich bisher selten gesehen und könnte ihnen spontan wenig Nutzen zuordnen (außer in einer Datenbankadministrationapplikation). Der Vollständigkeit halber würde ich diese Funktionalität aber auch gerne implementieren.

Ihr merkt vielleicht das mein "Konzept" noch eher ein grober Gedanke ist aber ich denke es ist klar geworden worauf ich hinaus möchte und was mein Ziel ist.

Es würde mich auch freuen von euch zu hören wie ihr so etwas implementieren würdest und was ihr von meinem Konzept haltet. Dazu sei gesagt das ich gerne Räder neu erfinde denn wenn man Räder niemals neu erfinden würde gäbe es ja keine Konkurrenz mehr....

__________________
Möglicherweise kommt zu "Menschen lügen" auch "Menschen bauen Mist".

Mister Ad

Phoscur

Alles gute Gedanken, wurde aber alles bereits gedacht
Für den Anfang sollte deine Wahl auf PDO fallen, wenn du nicht doch gleich ein Framework einsetzt. Du kannst dir ja auch mal ORM Systeme ansehen.

Tatsächlich erzeugst du damit aber einen gewissen Overhead, anfangs solltest du überlegen wie flexibel du das Design überhaupt haben willst. Manchmal ist diese ganze Komplexität einfach unnötig. Zumindest bei Websites.

__________________

illuminatus

Hallo,

entspricht dein Konzept nicht genau dem eines generischen OR-Mappers?

Oder wo genau besteht der Unterschied?

Gruß, illu

robo47

Gerade Datenbank-Abstraktionen gibt es ja zuhauf ... aber egal

Also gerade wenn du eine Abstraktion entwickeln willst solltest du das ja z.b. auch mit mehr als einem Datenbank-System testen, also nicht nur mysql, sondern auch, postgresql, sqlite, mssql, oracle, ...
-> PHP: PDO Drivers - Manual

Allein das alles aufzusetzen, unittests zu schreiben für die einzelnen Systeme ... ausserdem das ganze Wissen über die systeme, ihre Eigenheiten, um auch halbwegs gut testen zu können (Und zu wissen WAS deine Grundklasse/Interface alles können muss, sonst kannst du die abstraktion in der pfeife rauchen) ... was man alles beachten muss, was welche systeme unterstützen und was nicht, welche zeichen nutzt man um spaltennamen, welche um tabellennamen, welche um datenbanknamen (Abhängig vom System und Fall können das Backticks (`), anführungszeichen ("), hochkomma('), .... ), welche Mechanismen haben andere systeme, stichwort auto_increment bei mysql/sqlite und bei anderen DBMS sind das Sequenzen, .... .

Wie unterstützt du nützliche Features die vielleicht nicht alle Systeme können (oder noch schlimmer nicht jedes Backend eines Systems ?) z.b. Transaktionen.

Wie behandelst du Datentypen beim escapen, was für Datentypen MUSS es geben, fürs escapen im hinblick auf verschiedene DBMS (muss man vielleicht für ein dbms gewisse werte anders escapen ... ) inwieweit gibt es Spezialfälle in Systemen die der Adapter abdecken/unterstützen muss.
Wie werden Datentypen beim abrufen behandelt, geben Systeme integer auch als integer zurück oder nicht ? Gibt es da eventuell Probleme mit überläufen, ... )

Ausserdem wenn du richtig abstrahierst, heißt das nicht einfach PDO nutzen, sondern für JEDES DBMS einen passenden wrapper um PDO zu schreiben, da sie wie schon erwähnt verschiedene Zeichen für um Tablennamen, Spaltennamen, Datenbanknamen und Werte besitzen ...

Und dann ist es auch kein problem (nur zeitlicher aufwand für schreiben + tests ) für alle user die kein pdo haben je einen eigenen datenbank-adapter zu schreiben für die nativen mysql/mysqli/sqlite-funktionen.
Das ist ja eben sinn und zweck von solchen systemen, dass man beliebig die adapter austauschen kann, bedeutet aber dass du für eine vernünftige datenbank-abstraktion dich erstmal mit allen "potentiellen" systemen auseinandersetzen musst.

Auch die Entscheidung inwieweit du z.b. prepared statements nativ nutzt oder extra unterstütztst und was du bei extensions machst die das nicht unterstützen ? Selbst wrappen ? Oder throw new Exception('Feature not supported on FOO-DBMS');

Ausserdem schau dir mal andere Systeme an die Abstraktion bieten, ADODB, Zend_Db oder einen Schritt weiter gehen Richtung ORM: Doctrine, Propel.
Und dann schau wie viel CODE dahinter steckt, was an unittests vorhanden ist (insbesondere wie viele teilweise auch dbms-spezifische bugs es gab und für die dann tests existieren und soweiter, das Rad neu zu erfinden bedeutet ein verdammt großes Rad mit vielen kleinen drin neu zu erfinden, wenn du wirklich die tausendeste Abstraktion schreiben willst und nicht den eine million und ersten OOP-wrapper um db-funktionen

So genug allgemeines, jetzt detailiert zu deinem Post

Nur um es nochmal zu erwähnen, eben das ist das Problem, wenn du eine Abstraktion schreibst, muss deine Basisklasse und das Interface für möglichst alles gerüstet sein, da reicht es nicht sich mal mit mysql zu beschäftigen sondern man muss sich zumindest mit mehreren DBMS beschäftigen.

Auch wenn es stark vereinfacht ist, zeigt es schon perfekt ein Problem, du gibst eben KEINE dem dbms/extension spezifischen dinge zurück, SONDERN etwas allgemeines, wenn du also ein query machst, musst du da ein result-objekt zurückgeben.
Sowas wie public function fetch_array()... hat nichts in der Datenbanklasse zu suchen sondern dann im Result.

(Natürlich ein stark vereinfachtes Beispiel)

Macht das Sinn? Würde ich die PDO verwenden bliebe mir dieser Zusatzaufwand erspart. Nur wäre PDO dann eine (ggf. weitere) Abhängigkeit ohne die mein System nicht lauffähig wäre.
[/quote]

Wie schon gesagt, nein, bleibt er nicht, bei ner Abstraktion musst du dich um mehr kümmern, weil du ja z.b. dann auch sowas hast:
Da musst du ja dann wissen wie das spezifische DBMS das ganze behandelt, bei mysql alle spalten, datenbanken, tabellen in backticks und string-werte in Hochkomma.

Ist ein Ansatz, aber es gibt um so ein System zu schreiben auch Richtung ORM, verschiedene Ansätze und passende Patterns die ihre Vorteile und Nachteile haben:

P of EAA: Table Data Gateway
P of EAA: Row Data Gateway
P of EAA: Active Record
P of EAA: Data Mapper
P of EAA: Query Object

Allgemein kannst du ja mal
Catalog of Patterns of Enterprise Application Architecture durchschauen was es noch an Patterns gibt die für eine Abstraktion Sinn machen (können) und was dir davon mehr liegt oder nicht.


[quote]
Meine Frage an euch ist nun wie sinnvoll es ist ein ähnliches System in PHP umzusetzen. Als Beispiel nehemn wir eine Klasse Database welcher im Konstruktor ein Objekt übergeben bekommt welches das Interface IDatabaseConnection implementiert. Die Database-Klasse stellt Methoden zur Verfügung wie getTable() über welche man sich für eine bestimmte Tabelle ein DBTableObjekt holen kann um Felder oder Zeilen auszulesen welche durch DBFieldund DBRow Objekte repräsentiert werden.
Denke dran dass bei den unterschieden zwischen den DBMS es oftmals bedeutet dass du nicht Entwicklungszeit für Feature X hast, sondern Entwicklungszeit für Feature X * unterstützte DBMS.
Z.b. Welche Arten von joins welche systeme unterstützen und soweiter ....

Ja Das Rad neu zu erfinden.

Was mich gerade etwas stört ist das Gefühl dass du eine spontane Idee hattest ohne zu wissen auf was du dich einlässt. Du hast dir wahrscheinlich noch nicht andere Abstraktionen und ORM-Systeme mal mehr als nur flüchtig angeschaut um abschätzen zu können was auf dich zukommt.
Die Begrifflichkeiten im Text klingen so wie wenn du dir auch in Frage kommende Pattern nicht wirklich ein Begriff sind, was bei einem solchen Projekt zwangsläufig Pflicht ist.

Bisher sehe ich da eine kleine Idee, kein Konzept Und das ist mit allem dem was du gerne willst (und was dir während der konzeption vielleicht noch an Ideen kommt) meiner Meinung nach ein um ein vielfaches größeres Rad als die MVC/Routing/Mailing/Caching/Form-Räder zusammen

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

nikosch

Oh man, ich liebe es, wenn Robo seine Monsterantworten rausfeuert.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

robo47

Viel mehr als bissel Texte tippen und mal ne webseite aufmachen gab mein Notebook die letzte Stunde aufgrund von installations und kompilierungs-arbeiten (aktuelles mysql workbench aus den sourcen kompiliert + passende abhängigkeiten) auch nicht her ..., netbeans hat die code-completion nur geruckelt :P

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

nikosch

Hab mir heute endlich mal die Zeit genommen, die 6.8 halbwegs ordentlich einzurichten. Schiebe das schon mehrere minor-Versionen vor mir her. Leider konnte 6.5 noch keine Config-Exporte.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

robo47

Das ist ärgerlich, bis man dann immer alle Kleinigkeiten wieder so hat wie man es will / gewohnt ist

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

nikosch

[OT]
Ja. Natürlich noch kein Vergleich zu Eclipse (jedenfalls in meiner Erinnerung).

Sorry fürs Thread-Kapern.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Dark Guardian

Find ich gut. Die Antwort war sehr ausführlich und detailliert und hat mir extrem weiter geholfen. Ich würde auch gerne so detailliert darauf eingehen, aber bis ich die Patterns durchgeackert habe (einige sind mir von Berfuswegen schon begegnet ohne das ich es wusste XD) warte ich damit noch etwas.

Wie gesagt möchte ich im Prinzip Routineaufgaben abfrühstücken und versuchen nur diese zu vereinheitlichen. Alle DBMS unterschiede unter einen Hut zu bringen wäre für mein Ziel zuviel des Guten und wohl auch nur in extremen Spezialfällen der Anwendung meiner geplanten Applikation nötig.

Und selbst wenn ich damit nicht fertig werde bleibt der Lerneffekt. Z.B. deine gesammelten Links werden mir denke ich weiterhelfen. Es ist halt schwierig in Bereichen mit denen man sich zwar schon beschäftigt und gearbeitet hat ohne Eigeninitiative weiter zu kommen wo ich persönlich finde das selber ein bisschen basteln mehr bringt als nur 100000 Artikel zu lesen (vom Verständniss der Problematiken her). Selber amchen hat mir im Prinzip meist mehr geholfen als nur etwas zu lesen....

Glasklare Sache. War ja auch nur ein Beispiel...

Dann war es wohl zu stark vereinfacht weil es anscheinend nicht das verdeutlichte was ich sagen wollte. x) Es ging mir um die grobe Vorstellung des Adapters ohne Tiefer in die eigentliche Abstraktion hinein zu gehen. Mein Schmierzettel erweitert sich zumindest zunehmend....

Ich bedanke mich jedenfalls schonmal recht herzlich. Wenn jemand noch Dinge hinzuzufügen hat möge er es bitte tun. Ich bin für alles offen.

__________________
Möglicherweise kommt zu "Menschen lügen" auch "Menschen bauen Mist".