MS SQL und Standards

Werbung:
Das ist schon seit (mindestens) SQL:2003 Teil des SQL Standards.
Immer wieder interessant. Schade dass der so teuer ist, andererseits auch keine Sonntagabend Lektüre.
Hab mal nachgeschaut, seit Postgres 8.4 in der Doku aufgeführt, also 2009? Die Version ist seltsamerweise nicht in Wikipedia aufgeführt.

Also keine Erfindung von Microsoft.
Wer weiß? Keine Ahnung wer in dem Komitee sitzt, die großen DB Hersteller haben dort bestimmt was zu sagen. Wäre nur merkwürdig, dass sie es erst jetzt umsetzen.
 
Wäre nur merkwürdig, dass sie es erst jetzt umsetzen.
Finde ich nicht.
Für Microsoft war der SQL Standard sehr lange ziemlich nebensächlich (meiner Meinung nach).

Immer wieder interessant. Schade dass der so teuer ist, andererseits auch keine Sonntagabend Lektüre.
Es gibt zumindest die formale Syntaxdefinition öffentlich zugänglich, z.B. hier:

Wenn ich das richtig sehe, wurden Window Funktionen in SQL:2003 eingeführt (weil sie in SQL:1999 nicht auftauchen) und gleich mit der "Window Clause"
 
Ja, stimmt, MS ist mir diesbezüglich nie positiv aufgefallen, im Sinne von Bemühen um Standards, nicht mal bei eigenen Produkten, geschweige darüber hinaus. Vielleicht ändert sich das seit einiger Zeit etwas.

Die Syntax bis 2003, BNF und HTML Varianten hatte ich gerade gefunden, aber danach wieder Flaute, also 2006 usw.
Hier z.B.

Ich weiß nicht, ob die Komiteemitglieder von den Tantiemen ihrer Arbeit leben müssen. Dann müssen sie offenbar Entscheidungen treffen: entweder die Brötchen auf dem Tisch bezahlen und die Arbeit jedem einzeln als Buch verkaufen oder Standards definieren, die jeder kennt ...

Meine Vermutung wäre, dass man bei MS bspw. minimal die Syntax der Konkurrenz beherrschen muss, wenn man dort erfolgreich Kunden abringen will. Ob das Standard ist oder proprietär, ist dann vermutlich auch egal. Parallel am besten mit der eigenen Software möglichst jenseits des Standards entwickeln, damit der Vendor Lock-In die eigenen Kunden in Schach hält.
 
Da die Änderung nur die Syntax betrifft und die alte Syntax nach wie vor gültig bleibt werden wohl viele einfach gar nichts im Code ändern. Der Vorteil ist zu gering und man möchte ja nicht ohne Not unkompatibel zu irgendwas werden.
 
Da die Änderung nur die Syntax betrifft
mmh, abgesehen davon, dass ich hier wieder rum spekuliere: wenn ein Standard definiert ist und man den erfüllen kann (für eine andere parsing Variante, Funktion bereits implementiert), warum sollte man es nicht einsetzen und zu was würde man dabei inkompatibel werden? Zum Standard jedenfalls nicht. Man wird nur mächtiger.

Lesbarkeit erhöhen ist ja so oder so nicht verkehrt.

Wie bereits geschrieben (Spekulation), etwas verdeutlicht: Wenn ich ein Oracle Database Projekt zur Migration an Land ziehe und da gibt es tonnenweise solche Statements (SQL Standard, aber leider inkompatibel zu SQL Server), die migriert werden müssen, dann kann das mit ein paar kleinen gemeinen Fehlern bei der Migration zu bösen Überraschungen im Betrieb führen. Die Statements laufen nach der Migration natürlich ohne Fehler zu werfen, vielleicht gab es sogar (unzureichende) Test Units, aber ob man bei Over Partition By ..Order by.. ein Feld vergessen hat oder falsch rum sortiert, macht doch irgendwann einen Unterschied. Vielleicht wird das erst nach Monaten bemerkt bzw. die Ursache gefunden.
Da geht leicht eine "Success Story" flöten und etwas Reputation / ein interessanter Kunde.
Die Standards zu beherrschen (wo die Konkurrenz es bereits kann) ist also im Zweifel sehr wertvoll / kostensparend. Selbst wenn es kein Performancegewinn zur Laufzeit oder signifikante Vereinfachung im Code bringt.
 
Wie bereits geschrieben (Spekulation), etwas verdeutlicht: Wenn ich ein Oracle Database Projekt zur Migration an Land ziehe und da gibt es tonnenweise solche Statements (SQL Standard, aber leider inkompatibel zu SQL Server), die migriert werden müssen, dann kann das mit ein paar kleinen gemeinen Fehlern bei der Migration zu bösen Überraschungen im Betrieb führen. Die Statements laufen nach der Migration natürlich ohne Fehler zu werfen, vielleicht gab es sogar (unzureichende) Test Units, aber ob man bei Over Partition By ..Order by.. ein Feld vergessen hat oder falsch rum sortiert, macht doch irgendwann einen Unterschied. Vielleicht wird das erst nach Monaten bemerkt bzw. die Ursache gefunden.
Da geht leicht eine "Success Story" flöten und etwas Reputation / ein interessanter Kunde.
Die Standards zu beherrschen (wo die Konkurrenz es bereits kann) ist also im Zweifel sehr wertvoll / kostensparend. Selbst wenn es kein Performancegewinn zur Laufzeit oder signifikante Vereinfachung im Code bringt.
Der einzige, der da runter leidet ist der ausführende Dienstleister. Da dieser, nach deiner Spekulation, die Migration nicht beherrscht und das ist einem Softwarehersteller ziemlich egal. Und selbstverständlich implementiert ein Hersteller nichts was zu Performanceverlust zur Laufzeit führt, nur um einem Standard zu genügen. Ergibt einfach keinen Sinn.
 
Werbung:
Erstmal ist es doch gut, dass mehr Standards erfüllt werden.
Aber ich glaube nicht, dass es allein um das Wohl und Wehe des Dienstleisters geht, der eine Migration macht. Klar, der hat im Normalfall als erstes die A-Karte.
Große und sehr große Projekte laufen aber nicht nur vom DL aus, sondern auch vom Anbieter Vertrieb, also MS. Wenn der es schafft, so ein Projekt zu gewinnen, hängt er mit drin. Ein einzelnes SQL und der zugehörige Standard ist da sicher nicht die Frage, eher Gesamtbudget und Zeitrahmen. Wie IT Projekte dann allgemein aus dem Ruder laufen können, muss ich sicher nicht erläutern.
Am Ende wird aus einem Prestigeprojekt leicht ein Problemfall. Auch ein Hersteller verspürt an der Stelle dann vielleicht Schmerzen. Kommt auf die Verträge an, also die Kohle (und auch schlechte Publicity).
Am Ende ist es für mich nicht primär eine Frage der SQL Standards, die MS erfüllt, sondern welche es überhaupt gibt und wie zugänglich die sind. Und ich frage mich auch, nach welchen Kriterien Kunden soetwas entscheiden (können). Vermutlich schlechter als ich bspw., aber ich habe ja im Grunde selbst keinen guten Überblick.
Ich habe mir aus gegebenem Anlass neulich mal wieder irgendwelche Ratings angeschaut. Der Vergleich solcher Systeme ist nicht einfach, im Sinne der Vergleichbarkeit von relevanten, harten Fakten. Wenn ich bei Vergleichskriterien lese "Anzahl der Stellenangebote, Postings bei SO, ...", tja.. was soll einem das sagen? Wie wärs mit Dingen wie Prozent des aktuellen SQL Standard, Concurrent Sessions per Core / Memory oder anderen messbaren Concurrency Merkmalen?
Leider ist es an diesen Stellen mein Eindruck, dass die kommerziellen Anbieter hier relativ einfach Wände hoch ziehen (sie können es sich 1. leisten und 2. entsprechende Lizenzbestimmungen formulieren), wo die Leistungsfähigkeit und auch das Konzept von OS und der Community gegen verlieren. Das macht belastbare, sachliche Vergleiche schwierig.
Das finde ich anstrengend, es macht auch Kundengespräche nicht einfach.
 
Zurück
Oben