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

8

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?

s.demuro
quelle
3
Portabilität ist ein schönes Lehrbuchziel, kommt aber in der Praxis selten vor. Wenn Sie zwischen Standard-Syntax ( <>) und Nicht-Standard ( !=) wählen können, bei denen keine Kompromisse bei Leistung oder Wartbarkeit eingegangen werden, wähle ich immer Standard. Aber wenn es um andere Kosten geht oder es kein Standardäquivalent gibt, tippe ich aus und gehe proprietär. Die Dinge, die Sie aufgeben, nur um später die Plattform im Großhandel komplett zu wechseln, sind es imho einfach nicht wert.
Aaron Bertrand
6
Die einzige Zeit, in der Portabilität ein realistisches Ziel ist, ist das Schreiben einer App, die gleichzeitig in mehrere Plattformen integriert werden muss, da Ihre Kunden unterschiedliche Plattformen verwenden. Selbst dann, wenn Sie nicht möchten, dass die Funktionalität eingeschränkt und die Leistung auf allen Plattformen schrecklich ist, würde ich Pakete versenden, die die Funktionen einzelner Plattformen nutzen sollen.
Aaron Bertrand
1
Nur neugierig; Haben Sie in der Geschichte von je persönlich das Datenbanksystem geändert, das eine App für ein anderes System gleicher Qualität verwendet hat (z. B. Oracle -> SQLS)? Ich habe nicht
Caius Jard
2
Das andere, worauf ich neugierig war; Wie viel von Ihrem Prototyp überlebt vernünftigerweise, um ein vollständiges Produktionssystem zu sein? Die meisten meiner Prototypen teilen fast keine Aspekte mit den vollständigen Systemen, die aus ihnen geschrieben wurden, nachdem der Proto ein Konzept bewiesen und einige vernünftige Ansätze für das Aussehen einer Lösung ausgearbeitet hat. Machst du deine Prototypen zu perfekt / hängst du zu lange daran?
Caius Jard

Antworten:

16

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

Josh Darnell
quelle
11

Erzwingen Sie STD SQL nicht.

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

McNets
quelle
9

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.
Martin Smith
quelle
3

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

Marbry Hardin
quelle