nicht angemeldet
echo $begrüßung;
ich stehe hier grad vor der Wahl einer Datenbankklasse.
[...] Da bieten fertige Klassen mir einfach die Möglichkeit, den Datenbankserver "unterm Ar***" auszutauschen und ich brauche an meinen PHP-Skripten nichts ändern.
Das ist eine Illusion, die sich nur dann nicht in Enttäuschung auflöst, wenn die verwendeten SQL-Statements in der Form auch im neuen System laufen. Damit schränkt man sich teilweise erheblich in der verwendbaren Funktionalität ein.
Welche Gründe für einen Wechsel kann es denn geben?
- Anwendung zieht um, wobei auf dem Zielsystem _nur_ ein anderes DBMS zur Verfügung steht.
- DBMS wird getauscht, um Leistungsmerkmale des neuen Systems nutzen zu können.
- Einfach so.
Ein Wechsel ist nicht eben mal schnell durch Austausch der Verbindungsdaten zu erreichen. Danach sollte ein umfassender Test stattfinden, der aufzeigt, dass alles bzw. das was nicht läuft. Oder die Anwendung muss so umgeschrieben werden, dass die neuen Leistungsmerkmale genutzt werden können.
Jetzt frage ich mich im Wald dieser ganzen Datenbankklassen aber, welche ich verwenden sollte:
Das ist eine Entscheidung, die du selbst treffen musst, denn nur du bist derjenige, der deine Anforderungen kennt. Ich kann nur empfehlen, zwischen Datenbank(abstraktionsschicht) und Anwendung noch eine Datenschicht einzuziehen. Diese stellt der Anwendung die Daten über definierte Schnittstellen zur Verfügung. Zum DBMS hin setzt sie die Anforderderungen in SQL-Statements um. Wenn wirklich mal das DBMS getauscht werden soll, muss nur diese Datenschicht berücksichtigt werden. Man kann sogar so weit gehen, nach "unten" hin ein anderes Speichermedium anzubinden, ohne dass die Anwendung davon Wind bekommt und dort Änderungen notwendig sind. Auch kann man diese Datenschicht während der Entwicklung Dummydaten liefern lassen, und die Implementation erst später ausführen.
Empfehlenswert ist auch, wenn du dir mal das MVC-Architekturmuster anschaust.
echo "$verabschiedung $name";