Modularität einer Datenbankklasse

[Forumsgast]

Hey Leute,

mir ist gerade beim lesen eines anderen Threads eine Frage eingefallen. Wenn ich jetzt eine Datenbank-Klasse habe die mehrere DB-Treiber unterstüzt wie soll das mit der Modularität funktionieren? Also ich meine was wenn ich 2 Klassen miteinander kommunizieren lasse, eine davon ist die o.g. DB-Klasse.

So nun soll an der einen stelle folgender SQL-String gesendet an die DB werden:

SELECT * FROM tabelle LIMIT 0,30

Das wird wunderbar funktionieren UNTER MYSQL. Stellt man diese Anfrage aber an einen MS SQL Server so wird der streiken, denn LIMIT gibt es bei MS SQL nicht.

Kann man sowas überhaupt abfangen?

Ist jetzt kein wirkliches Problem was ich hab. Die Frage ist mir nur gerade in den Sinn gekommen

Gruss
Tim

[Forumsgast]

Die Datenbank-spezifischen Klassen müssen dir eine Schnittstellen zur Verfügung stellen, die diesen SQL-Ausdruck in ihrem SQL-Dialekt darstellt.

Bei Zend_Db ist das z.B.

$db->select()->from("tabelle")->limit(0, 30)

Wenn du doch mal nicht drumrum kommst, solltest du deine SQL-Queries auslagern, damit du sie einfach gegen die einer anderen DB austauschen kannst.

Mehr auch hier:
http://www.phpfriend.de/forum/ftopic62997.html#435219
im unteren Bereich meines Postings.

[Forumsgast]

Dann bräuchte man doch erstmal eine Liste der Unterschiede zwischen den Queries oder nicht? Also um allgemein sowas abzufangen und dann muss man sich ransetzen und für jeden einzelnen Fall nen das ganze programmieren oder man programmiert es halt dazu wenn man es braucht... oder seh ich das jetzt falsch? Oder gibt es gar nich soviele Fälle wo das vorkommt?

[Forumsgast]

Die meisten Anwendungen beschränken sich doch ohnehin auf wenige feste Statements, die sich nur in den Parametern unterscheiden.
Du könntest bspw. in einem Array eine DBMS-spezifische Menge von SQL-Template-Strings vorhalten, in die dann e.g. mittels sprintf () die jeweiligen Parameter eingesetzt werden.

[Forumsgast]

Hallo cycap,

du denkst ein wenig falsch, wie ich finde. In dieser Situation benötigt man einfach eine weitere Abstraktionsschicht, die Datenschicht einer Anwendung. Damit hat man folgende Schichten:

1. Präsentationsschich
2. Businessschicht
3. Datenschicht
4. Treiberschicht

Innerhalb der Datenschicht werden kann die Spezifika eines Treibers berücksichtigt. Wenn du eine Applikatopm führ mehrer datenbanken entwickelst, wirst du genauso nochmal innerhalb der Datenschicht einen generischen Mapper bauen, der sich zum Laden und Speichern von Objekten aus der Business-Schicht die konkrete Implementierung je nach Config zieht und ausführt. Wichtig und grundlegend ist an dieser Stelle das Domain-Objekt-Modell, das besagt, dass du innerhalb der Anwendung ein eigenes ObjektModell (=Modell der Daten-Objekte)hast, das von der eigentlichen, physikalischen Datenhaltung getrennt existieren kann und wird. Schau dir mal das Dokument unter http://www.adventure-php-framework.o...plomarbeit.pdf an, das beschreibt den Entwurf einer Software unter diesen Kriterien. Hier wird zwar nur für MySQL implementiert, aber das Thema Domain-Model wird sauber behandelt.

[Forumsgast]

Es gibt ja Standard-SQL und entsprechende Dialekte, MySQL, Oracle, etc.
Jetzt versuchst du natürlich so weit wie möglich Standard-SQL zu verwenden und erst wenn es nicht mehr anders geht, spezifisch zu werden.

INSERT, UPDATE, einfache SELECT's sind wohl hauptsächlich gleich, unterschiedlich kann es bei JOIN, LIMIT, Insert-ID/Sequenzen usw. geben. Dann schreibst du dir eben ein abstraktes Konstrukt, dass wie bei Zend_Db datenbank-spezifisch eine LIMIT-Klausel beschreibt.

Ich denke die Zeiten sind vorbei, in denen man sich seine eigene Datenbank-Klasse schreibt. Ich wollt auch immer alles selbst machen und irgendwann merkst du dann, es gibt das alles schon, nur funktionierend und mit viel mehr Funktionen