Best Practices zur Maximierung der Portabilität in SQL Server 2016

Bei der Entwicklung des Prototyps einer Lösung sind die Technologien häufig noch nicht entschieden und stimmen möglicherweise nicht mit denen überein, die für das fertige Produkt verwendet werden.

In diesen Szenarien verwende ich normalerweise Microsoft SQL Server, um die Abfragen so standardmäßig wie möglich zu schreiben, um die eventuelle Migration auf einen anderen Server zu vereinfachen.

Gibt es eine Möglichkeit oder eine bekannte Praxis, die Verwendung von Standard-SQL über T-SQL-Dialekt direkt in SQL Server oder über SQL Server Management Studio (SSMS) zu erzwingen?

Benutzer Aaron Bertrand hat einige Kommentare abgegeben, die gut zu meinen Gedanken zu Ihrer Frage passen. Dies ist eher eine Rahmenherausforderung als eine Antwort auf Ihre spezifische Frage, aber ich denke, es ist wertvoll, dies in diesem Zusammenhang zu berücksichtigen.

Portabilität ist ein schönes Lehrbuchziel, kommt aber in der Praxis selten vor.

Wenn Sie irgendwann die Plattform wechseln müssen, sind Änderungen an der Anwendung, der Datenbank und wahrscheinlich vielen anderen Dingen erforderlich. Wenn Sie ohne großen Aufwand etwas "plattformunabhängig" sein können, ist das in Ordnung. Aber es ist wirklich eine schlechte Geschäftsentscheidung, dies als Designziel zu verwenden.

Es gibt viele Orte im Internet, an denen die Leute die Nachteile diskutieren oder auf diese Weise programmieren. Hier ist einer von ihnen, den ich ziemlich überzeugend finde:

Datenbank-Abstraktionsschichten müssen sterben!

Der Portabilitätsfehler

Der Autor verwendet ein Argument, das ich ständig höre: Wenn Sie eine gute Abstraktionsschicht verwenden, ist es einfach, später von $ this_database zu $ ​​other_database zu wechseln.

Das ist Blödsinn. Es ist nie einfach.

In einer nicht trivialen datenbankgestützten Anwendung hält es niemand für einfach, die Datenbank zu wechseln. Zu denken, dass "die Bekehrung schmerzlos sein wird", ist eine Fantasie.

Gute Ingenieure versuchen, die besten Werkzeuge für den Job auszuwählen und dann alles zu tun, um die einzigartigen und leistungsstärksten Funktionen ihres Werkzeugs zu nutzen. In der Datenbankwelt bedeutet dies spezifische Hinweise, Indizierungen, Datentypen und sogar Entscheidungen zur Tabellenstruktur. Wenn Sie sich wirklich auf die Teilmenge der Funktionen beschränken, die allen wichtigen RDBMS gemeinsam sind, tun Sie sich und Ihren Kunden einen großen Nachteil.

Das unterscheidet sich nicht von der Aussage "Ich beschränke mich auf die Teilmenge von PHP, die in Perl und C gleich ist, weil ich vielleicht eines Tages die Sprache wechseln und meinen Code 'schmerzlos' portieren möchte."

Das passiert einfach nicht.

Die Kosten für das Wechseln von Datenbanken nach der Entwicklung und Bereitstellung einer Anwendung sind recht hoch. Sie müssen möglicherweise Schema- und Indexänderungen, Syntaxänderungen, Optimierungs- und Optimierungsarbeiten wiederholen, Hinweise zum Anpassen oder Entfernen usw. Das Ändern von mysql_foo () in oracle_foo () ist wirklich das geringste Ihrer Probleme. Sie werden den größten Teil, wenn nicht den gesamten Teil Ihres SQL berühren - oder Sie müssen es zumindest überprüfen.

Das klingt für mich nicht "schmerzlos".

Erzwingen Sie STD SQL nicht.

Entscheiden Sie zuerst, welches DBMS Sie entsprechend den Anforderungen Ihres Projekts verwenden möchten, und nutzen Sie es.

Nicht wirklich.

Es gibt SET FIPS_FLAGGER 'FULL'.

Dies gibt eine Warnung für nicht standardmäßiges SQL aus - es gibt jedoch einige Einschränkungen

• Ich bin mir nicht sicher, welchen spezifischen Standard dies verwendet (und vermute, dass es sich um SQL 92 handelt).
• Nach einem kurzen Test beklagt sich dies nicht über die Verwendung des +Operators für die Verkettung von Zeichenfolgen oder proprietäre Funktionen, so GETDATE()dass er nicht sehr umfassend erscheint.

"Oft sind die Technologien noch nicht entschieden"

Ich würde sagen, dass dies meiner Erfahrung nach absolut NICHT der Fall ist. Tatsächlich glaube ich nicht, dass ich jemals davon gehört habe, außer vielleicht etwas sehr Kleinem.

In der Regel wird dies festgelegt, und es wird erwartet, dass die neue Lösung das verwendet, was bereits verwendet wird.

Ich würde den obigen Kommentatoren darin zustimmen, dass Sie dies zuerst festlegen müssen, bevor Sie mit dem Schreiben von Abfragen und anderem Code beginnen, auch wenn es nicht eingerichtet ist. Andernfalls lassen Sie sich möglicherweise sofort auf eine Menge verschwendeter Anstrengungen ein, um sofort neu zu schreiben.