Warum sind SQL-Distributionen trotz eines ANSI-Standards, der für SQL existiert, nicht standardkonform? Gibt es tatsächlich so viele sinnvolle Unterschiede in der Funktionsweise von SQL-Datenbanken oder sind es nur die beiden Datenbanken, mit denen ich gearbeitet habe: MS-SQL und PostgreSQL? Warum entstehen diese Unterschiede?Gründe für SQL-Unterschiede
Es ist eine Form von "Stealth Lock-In". Joel sehr ins Detail geht hier:
Unternehmen binden zu Nicht-Standard oder seltsame nicht unterstützte Funktionalität bei der Umsetzung ihrer Geschäftsfunktionalität am Ende, dies schränkt ihre Fähigkeit, sich zu bewegen von ihrem Verkäufer zu einem Konkurrenten.
Auf der anderen Seite ist es ziemlich kurzsichtig, weil jeder mit einem halben Gehirn dazu neigt, die proprietären Stücke wegzuzaubern, oder das Lock-In gänzlich zu vermeiden, wenn es zu ungeheuerlich wird.
Der ANSI-Standard spezifiziert nur eine begrenzte Anzahl von Befehlen und Datentypen. Sobald Sie darüber hinausgehen, sind die Implementierer auf sich selbst gestellt. Und einige sehr wichtige Konzepte werden überhaupt nicht angegeben, wie z. B. automatisch inkrementierende Spalten. SQLite wählt nur die erste Nicht-Null-Ganzzahl aus, MySQL benötigt AUTO INCREMENT, PostgreSQL verwendet Sequenzen usw. Es ist ein Durcheinander, und das ist nur unter den OSS-Datenbanken! Versuchen Sie, Oracle, Microsoft und IBM zu veranlassen, sich gemeinsam für eine knifflige Funktionalität zu entscheiden.
Es ist sicherlich wirksame Lock-in, wie 1800 sagt. Aus Gründen der Fairness gegenüber den Datenbankanbietern spielt der SQL-Standard jedoch immer die aktuellen Funktionen der Datenbanken ab. Die meisten Datenbanken, die wir heute haben, sind von ziemlich alten Linien. Wenn Sie Microsoft SQL Server zu seinen Wurzeln zurückverfolgen, werden Sie Ingres finden - eine der allerersten relationalen Datenbanken, die in den 70er Jahren geschrieben wurden. Und Postgres wurde ursprünglich von einigen derselben Leute in den 80er Jahren als Nachfolger von Ingres geschrieben. Oracle geht weit zurück, und ich bin mir nicht sicher, wo MySQL hereinkam.
Datenbank-Portabilität nicht saugen, aber es könnte viel schlimmer sein.
John: Der Standard deckt tatsächlich viele Themen ab, einschließlich Identitätsspalten, Sequenzen, Trigger, Routinen, Upsert usw. Aber natürlich wurden viele dieser Standardkomponenten möglicherweise später als die ersten Implementierungen eingeführt; und dies könnte ein Grund sein, warum die Einhaltung von SQL-Standards im Allgemeinen etwas niedrig ist.
Neall: Es gibt tatsächlich Bereiche, in denen der SQL-Standard den Implementierungen voraus ist. Zum Beispiel wäre es schön, CREATE ASSERTION zu haben, aber soweit ich weiß, implementiert noch kein DBMS Assertions.
Persönlich glaube ich, dass die Geschlossenheit einiger ISO-Standards (wie der SQL-Standard) Teil des Problems ist: Wenn ein Standard online nicht verfügbar ist, ist es weniger wahrscheinlich von Implementoren/Planern und auch bekannt Wenige Kunden verlangen Compliance, weil sie nicht wissen, wonach sie fragen sollen.
Erstens, ich finde Datenbanken nicht als Browser oder Betriebssysteme in Bezug auf Inkompatibilität. Jeder, der ein paar Stunden Training hat, kann mit dem Auswählen, Einfügen, Löschen und Aktualisieren von SQL-Datenbanken beginnen. In der Zwischenzeit ist es schwierig, HTML zu schreiben, das auf jedem Browser identisch rendert oder Systemcode für mehr als ein Betriebssystem schreibt. Im Allgemeinen beziehen sich Unterschiede in SQL auf die Leistung oder ziemlich esoterische Merkmale. Die größte Ausnahme scheinen Datumsformate und Funktionen zu sein.
Zweitens sind Datenbankentwickler im Allgemeinen motiviert, Features hinzuzufügen, die ihr Produkt von allen anderen unterscheiden. Produkte wie Oracle, MS SQL Server und MySQL sind große Ökosysteme, die sich in der Praxis selten gegenseitig befruchten. An meinem Arbeitsplatz verwenden wir Oracle und MySQL, aber wir könnten, wenn nötig oder gewünscht, in etwa einem Tag auf 100% Oracle wechseln. Ich sorge mich also sehr um die glänzenden Spielzeuge, die Oracle uns bei jeder Veröffentlichung gibt, aber ich weiß nicht einmal, welche Version von MySQL wir verwenden. IBM, Microsoft, PostgreSQL und der Rest könnten für uns ebenfalls nicht existieren. Die Funktionen zum Abrufen und Halten von Kunden und Benutzern sind weitaus wichtiger als die Kompatibilität in der Datenbank. (Das ist der positive Spin auf der "Lock-in" -Antwort, nehme ich an.)
Drittens gibt es legitime Gründe für unterschiedliche Unternehmen, SQL anders zu implementieren. Zum Beispiel verfügt Oracle über ein Multi-Versionierungssystem, das sehr schnelle und skalierbare konsistente Lesevorgänge ermöglicht. Anderen Datenbanken fehlt diese Funktion, aber normalerweise werden Zeilen schneller eingefügt und Transaktionen rückgängig gemacht. Dies ist ein grundlegender Unterschied in diesen Systemen. Es macht keinen besser als den anderen (zumindest im allgemeinen Fall), nur anders. Man sollte sich nicht wundern, wenn das SQL-ontop einer Datenbank-Engine seine Stärken ausnutzt und versucht, seine Schwächen zu minimieren. In der Tat wäre es unverantwortlich von den Entwicklern, dies nicht zu tun.
Ein weiterer Grund ist die Abwärtskompatibilität, die in Verbindung mit Features, die zu einem früheren Zeitpunkt nicht im Standard hinzugefügt oder hinzugefügt wurden, zu anderen Implementierungen führt, die später nur schwer zu entfernen sind (Beispiel: CROSS APPLY in SQL Server) die (näher zum Standard) 'LATERAL' in DB2 und Postgres,' CONNECT BY' in Oracle, machten sie Jahre vor dem Hinzufügen von rekursiven CTEs, 'LIMIT' /' TOP'/'FETCH FIRST' in verschiedenen DBMS, usw.). –