Hallo,
Aus eben diesem Grunde ist eine reine Datenbankabstraktion nur die halbe Miete. Man kann noch eine Schicht obendrauf setzen (oder beides zu einer verschmelzen), die nur noch die reinen Daten übergibt, dazu gegebenenfalls Parameter entgegennimmt. Die eigentliche Datenaufbewahrung und Beschaffung ist damit komplett verdeckt. Wenn man die bisherige Schnittstelle zur Geschäftslogik beibehält, kann man die Datenhaltung ändern, ohne dass die Anwendung davon etwas mitbekommt.
Danke für deine Antwort. Sprich ich übergebe keine Statements mehr an die Datenbank-Klassen sondern rufe bestimmte Methoden mit bestimmten Parmetern auf, die mir dann die Daten besorgen. Klingt gut.
Doch was mache ich z.B., wenn ich bei MySql das Datum im Statement formatiert hätte oder noch irgendeinen Join. Das ist ja nur schwer in sinnvolle Parameter etc zu packen, da fehlt mir die Idee.
zufälliges Beispiel aus dem Archiv:
SELECT * FROM table1 LEFT OUTER JOIN table2 ON table1.id=table2.old_id WHERE table2.ca_id IS NULL
Wie gestaltet man sowas sinnvoll?
Für
SELECT * FROM table1 WHERE id = 1
hätte ich z.B. an sowas gedacht $datenbank->get('*', 'table1', 'id = 1');
Das könnte ich dann intern nach Bedarf zusammenbauen.
Gruß