nicht angemeldet
echo $begrüßung;
Wenn ich bei der Implementierung davon ausgehe, dass ich diesen Backtick nutzen kann lande ich bei einer Anwendung deren Portierung auf eine andere Datenbank extrem aufwändig ist.
Meine Meinung als Datenbanklaie und programmiertechnischer Autodidakt ist, dass man im Hinblick auf Portierbarkeit jede Menge Abstriche machen muss. Um mal ein Beispiel zu nennen: Sequenzen scheiden ebenso aus wie auto_increment, weil das eine oder das andere Feature in dem einen oder anderen DBMS nicht zur Verfügung steht. Ebenso muss man sich bei der Benennung von Bezeichnern stark in Acht nehmen, dass man keinen erwischt, der in dem einen DBMS zwar verfügbar ist, in dem anderen aber reserviert ist. Je portierbarer die Anwendung werden soll desto allgemeiner muss man bleiben. Die Anwendung ist dann also wunderbar portierbar läuft aber möglicherweise auf jedem System nur auf Sparflamme. Alternativ kann auch die Datenbankabstraktionsschicht ein in einem der unterstützten DBMSe nicht vorhandenes Feature anderweitig nachbilden.
Ich ziehe aus diesem Grund mittlerweile die Methode mit den Parametern von Statements bei JDBC oder ADO vor, da hier der entsprechende Treiber die Erkennung der entsprechenden Typeigenheiten übernimmt. Aber gerade bei PHP dürfte es (ok, ich hab mich nicht ganz tief eingearbeitet...) Gang und Gebe sein, die Statements im Skript und nicht einem (austauschbaren) Datenbankobjekt zu lagern, so dass alle von Hand nachgezogen werden müssen.
Ja, das sieht so aus, weil wohl die meisten PHP-Anwender wenig Programmiererfahrung mitbringen und einfach so drauflos programmieren, wie es in der Anfängerliteratur gelehrt wird. Mehr Möglichkeiten als das gab es ja bisher (vor PHP 5) auch nicht - Datenbankabstraktionsschichten von Dritthersteller mal ausgenommen (PEAR zähle ich auch dazu) und mit MySQL-API-verblendeten Augen geschaut. Seit PHP 5 gibt es, wie wahsaga schon erwähnte, mysqli und seit PHP 5.1 steht PDO innerhalb PHPs zur Verfügung. PDO ist eine Datenbankabstraktionsschicht für so gut wie alle Datenbank-APIs die in PHP enthalten sind. PDO bietet aber "nur" eine einheitliche Programmierschnittstelle. (Statements mit Platzhaltern und automatischer Quotierung sind auch dabei.) Mann kann damit natürlich immer noch Querys absenden, die datenbankspezifisch sind, was ggf. einer Portierbarkeit im Weg steht.
Ich sehe ja durchaus den Vorteil, ich kenne Leute die Vergeben Tabellennamen mit Leerzeichen, da kommt man um sowas gar nicht umher, aber bei Access nach xyz müsste ich trotzdem [ ] durch irgendwas anderes ersetzen - sehr teuer. Ich ziehe es deshalb vor die Modelle so aufzubauen, dass eine derartige Syntax nicht erforderlich ist.
Datenbankabstraktionsschichten bringen schon mal einige Vorteile. Wenn man die Querys auch noch von einem Querybuilder zusammenbauen lässt, der Feldnamen, Tabellennamen, Werte usw. übergeben bekommt und mit einer datenbankkonformen Quotierung und Maskierung versieht, ist man auch schon mal einen Schritt weiter. Aber auch hier bleibt der Nachteil bestehen, dass man nur standardkonforme Abfragen verwenden kann, um portierbar zu bleiben.
Mittlerweile bin ich dazu übergegangen der Anwendungslogik nur noch eine Datenschnittstelle (man beachte das nicht vorhandene "bank") bereitzustellen. Von Querys und anderen datenbanktechnischen Details bekommt sie nichts mehr mit. Über die Schnittstelle werden nur einzelne Werte/Parameter oder Daten-Arrays/Objekte übergeben. Ja, es ist damit noch nicht einmal erforderlich, dass Datenquelle und -senke ein DBMS ist.
Innerhalb dieser Datenschicht kann ich alle Features nutzen, die mir die Datenbank so bietet. Die Querys können komplett vorhanden sein oder auch in die einzelnen Klauseln zerlegt vorbereitet sein, damit man beispielsweise auch mal der WHERE-Klausel flexibel Bedingungen hinzufügen kann. (PEARs DB_Table diente mir als Ideengeber.)
Eine spätere Portierung ist damit zwar nicht durch einfaches Austauschen der darunter liegenden Datenbankabstraktion bzw. durch Ansprechen eines anderen Treibers dieser DBA erledigt, doch das ist der Kompromiss, den ich an der Stelle eingehe, um die Fähigkeiten des DBMS bestmöglich nutzen zu können. Falls ich also mal portieren möchte, muss ich diese Datenschichtdateien anpassen, kann dann aber auch gleich wieder alle Features des neuen DBMS verwenden.
echo "$verabschiedung $name";