Da alle SQL-Server unterschiedliche Teile des SQL-Standards implementieren, ist die Entwicklung portierbarer Datenbankanwendungen sehr aufwändig. Bei sehr simplen Auswahl- und Einfügeoperationen mag die einfache Portierbarkeit noch gegeben sein, aber je mehr Funktionalitäten Sie benötigen, umso komplexer wird sie. Wenn Sie eine Anwendung brauchen, die auf vielen verschiedenen Datenbanksystemen schnell ist, wird es noch schwieriger.

Alle Datenbanksysteme haben Schwachpunkte: Entwicklungsseitig enthalten sie Kompromisse, die ein unterschiedliches Verhalten verursachen.

Um eine komplexe Anwendung portierbar zu machen, müssen Sie zunächst ermitteln, auf welchen SQL-Servern sie laufen muss, und dann bestimmen, welche Funktionen diese Server unterstützen. Sie können mit dem MySQL-Programm crash-me Funktionen, Typen und Einschränkungen ermitteln, die für eine Auswahl von Datenbankservern gelten. crash-me prüft nicht alle denkbaren Funktionen, ist aber mit etwa 450 Tests vergleichsweise umfassend. Ein Beispiel für die Art von Informationen, die sich mit crash-me ermitteln lassen, ist etwa die Tatsache, dass Sie keine Spaltennamen verwenden sollten, die mehr als 18 Zeichen umfassen, wenn Sie Informix oder DB2 einsetzen wollen.

Das Programm crash-me und die MySQL-Benchmarks hängen stark von der jeweiligen Datenbank ab. Sehen Sie sich einmal an, wie sie geschrieben sind, um ein Gefühl dafür erhalten, was Sie tun müssen, um Ihre eigenen Anweisungen so datenbankunabhängig wie möglich zu machen. Sie finden die Programme im Verzeichnis sql-bench der MySQL-Quelldistributionen. Sie sind in Perl geschrieben und verwenden die DBI-Datenbankschnittstelle. Bereits die Verwendung von DBI löst das Portabilitätsproblem teilweise, denn die Schnittstelle bietet datenbankübergreifende Zugriffsmethoden. Siehe auch Abschnitt 7.1.4, „Die MySQL-Benchmark-Reihe“.

Wenn Sie nach Datenbankunabhängigkeit streben, brauchen Sie ein gutes Gespür für die Engpässe auf den einzelnen SQL-Servern. So ist MySQL beispielsweise sehr schnell, wenn es um das Abrufen und Aktualisieren von Datensätzen in MyISAM-Tabellen geht, hat aber Probleme bei Fällen, in denen gleichzeitig langsame Lese- und Schreibvorgänge verwaltet werden müssen. Oracle andererseits zeigt sich ausgesprochen widerspenstig, wenn Sie auf Datensätze zugreifen wollen, die Sie kürzlich aktualisiert (und noch nicht auf Festplatte synchronisiert) haben. Transaktionssichere Datenbanksysteme sind generell nicht besonders gut zur Erstellung von Zusammenfassungstabellen aus Logtabellen geeignet, weil in diesem Fall die Sperrung von Datensätzen praktisch nutzlos ist.

Um Ihre Anwendung wirklich datenbankunabhängig zu machen, sollten Sie eine leicht zu erweiternde Schnittstelle definieren, über die Sie Ihre Daten manipulieren. C++ beispielsweise ist auf den meisten Systemen verfügbar, weswegen es sinnvoll ist, eine Datenbankschnittstelle auf Basis einer C++-Klasse zu verwenden.

Wenn Sie die eine oder andere Funktion verwenden, die für ein gegebenes Datenbanksystem spezifisch ist (z. B. die MySQL-Anweisung REPLACE), dann sollten Sie dieselbe Funktion für andere SQL-Server implementieren, indem Sie eine alternative Methode einkodieren. Auch wenn diese Alternative langsamer ist, so erlaubt sie es anderen Servern doch, dieselben Aufgaben auszuführen.

Bei MySQL können Sie mit der Syntax /*! */ MySQL-spezifische Schlüsselwörter zu einer Anweisung hinzufügen. Der Code in /* */ wird von den meisten anderen SQL-Servern als Kommentar betrachtet (und insofern ignoriert). Informationen zum Schreiben von Kommentaren finden Sie in Abschnitt 9.4, „Kommentar“.

Wenn die Leistungsfähigkeit wichtiger ist als die Genauigkeit (wie es beispielsweise bei Webanwendungen der Fall ist), dann können Sie eine Anwendungsschicht erstellen, die alle Ergebnisse zwischenspeichert, um die Performance noch besser zu optimieren. Indem Sie ältere Ergebnisse nach einer bestimmten Zeit ungültig werden lassen, können Sie den Cache ausreichend aktuell halten. Auf diese Weise können Sie Belastungsspitzen abfangen, indem Sie die Cache-Größe dynamisch erhöhen und den Ungültigkeitszeitpunkt nach hinten verschieben, bis sich die Belastung wieder normalisiert hat.

In diesem Fall sollten die Angaben zur Tabellenerstellung Informationen zur ursprünglichen Cache-Größe und dazu enthalten, wie oft die Tabelle normalerweise aktualisiert wird.

Eine interessante Alternative zur Implementierung eines Anwendungs-Caches ist die Verwendung des Abfrage-Caches von MySQL. Wenn Sie den Abfrage-Cache aktivieren, bestimmt der Server selbst, ob ein Abfrageergebnis wiederverwendet werden kann. Dies vereinfacht Ihre Anwendung. Siehe auch Abschnitt 5.14, „MySQL-Anfragen-Cache“.