it-swarm.com.de

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?

8
s.demuro

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, werden Änderungen an der Anwendung, der Datenbank und wahrscheinlich vielen anderen Dingen erforderlich sein. 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:

Datenbankabstraktionsebenen 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 ist es für niemanden 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 ist nichts anderes als zu sagen: "Ich beschränke mich auf die Teilmenge von PHP, das ist in Perl und C gleich, weil ich vielleicht eines Tages die Sprache wechseln und meine" schmerzlos "portieren möchte Code."

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".

16
Josh Darnell

Erzwingen Sie STD SQL nicht.

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

11
McNets

Nicht wirklich.

Es gibt SET FIPS_FLAGGER 'FULL' .

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

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

"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.

3
Marbry Hardin