Ist es sinnvoll, die Klammernotation von SQL Server in handgeschriebenem Code zu verwenden?

Codegeneratoren sind in der Regel einfacher, wenn sie []für fast alles Ausgaben mit der neuen Microsoft-Klammernotation ( ) generieren .

Als ich es zum ersten Mal sah, war es eine Reinkarnation der etwas verbotenen Notation.

Soweit ich weiß, handelt es sich um eine proprietäre Erweiterung von Microsoft (was bedeutet, dass Oracle sie nicht unterstützt).

Bei SQL Server gibt es keinen Unterschied, wenn Sie eine Tabelle wie definieren

CREATE TABLE [dbo].[Table_2] ([col1] [int], [col2] [int]);

oder

CREATE TABLE dbo.Table_2 (col1 int, col2 int);

Es ist eine Frage des persönlichen oder geschäftlichen Stils. Seien Sie konsequent.

Wenn Sie jetzt Ihre Datenbank nach Oracle migrieren möchten, sind Klammern keine Option.

Sie können die alten, in Anführungszeichen gesetzten Bezeichner verwenden, bei denen jedoch die Groß- und Kleinschreibung beachtet wird, was große Probleme verursacht.

Ist es eine gute Idee, alle Klammern aus dem generierten Code zu entfernen, Leerzeichen, andere Sonderzeichen und reservierte Schlüsselwörter für Namen zu vermeiden und nur Code in einer Weise zu verwenden, die die meisten DBMS verstehen?

Standard-SQL verwendet das doppelte Anführungszeichen "für Bezeichner in Anführungszeichen. SQL Server unterstützt dies mit der QUOTED_IDENTIFIEROption ( ANSI_QUOTESin mySQL). Standard-SQL verbessert die Portabilität im Allgemeinen und würde in diesem Fall auf Oracle portieren. Ebenso würde ich SQL-Schlüsselwörter in Großbuchstaben ändern (Intermediate SQL-92-Anforderung) und intauf INTEGER(Entry Level SQL-92-Anforderung) erweitern.

Die unnötige Verwendung von Bezeichnern in Anführungszeichen, unabhängig vom Geschmack, sollte vermieden werden, IMO.

Dies ist ein subjektives Problem, aber unnötige Klammern stehen ganz oben auf meiner Liste der Tierhüllen - etwas ärgerlicher als die falsche Schreibweise von "! =", Aber nicht so schlimm wie führende Kommas in Spaltenlisten.

Betrachten Sie objektiv den Zweck von Klammern: Zulassen von Objektnamen, die ansonsten nicht zulässig wären. Aus diesem Grund sind Klammern im schlimmsten Fall ein Code-Geruch und im besten Fall ein Zeichen von Faulheit.

• Klammern sind erforderlich, wenn Ihre Tabellen- oder Spaltennamen:

  • Enthält ein Leerzeichen: SELECT [column name] FROM table;
  • eine Klammer enthalten:, SELECT [wt[f]oderSELECT [wt]]f]
  • enthalten ein nicht alphanumerisches Symbol wie ^oder !(ja, sie können diese Symbole enthalten!)
  • sind reservierte Schlüsselwörter wie KEY, STATE, RULE, ...

  Wenn Sie die Kontrolle über das Schema haben, sollten Sie natürlich solche Namen vermeiden. In einigen Fällen ist der beste Name jedoch ein reservierter Name (wie KEYfür die Schlüsselspalte in einer generischen Schlüsselwerttabelle), sodass Sie entscheiden müssen, wie schlecht Sie ihn verwenden möchten (und ihn daher überall zitieren müssen).

  Ich verwende auch eckige Klammern, um die blaue Hervorhebung zu unterdrücken, die SSMS und VS einigen Schlüsselwörtern geben DESCRIPTION, die von SQL Server nicht reserviert sind, ansonsten aber speziell für diese Tools gelten.

• Verwenden Sie beim dynamischen Generieren von SQL unbedingt Klammern. Die einfachste Möglichkeit besteht darin, QUOTENAME()die Objekte aufzurufen, auf die Sie dynamisch verweisen (z SELECT QUOTENAME(name) FROM sys.databases;. B. ). sp_MSforeachdbDas macht zum Beispiel nicht .

Wenn ich Code schreibe, der Code generiert, setze ich die eckigen Klammern um Datenbankobjektnamen. Beim Schreiben von Code von Hand werden die Klammern nicht berücksichtigt, und die Lesbarkeit des Codes wird beeinträchtigt. Ich verbiete auch Datenbankobjektnamen mit Leerzeichen. In SQL Server können Sie Leerzeichen in Objektnamen verwenden. Dies bedeutet jedoch nicht, dass dies eine gute Sache ist.

Ich würde wahrscheinlich nicht einmal versuchen, tragbares DDL zu haben. Ich wäre besser dran, wenn ich Oracle-Tabellendefinitionen bei Bedarf aus den Systemansichten von SQL Server generieren würde.

Ich halte es auch nicht für sinnvoll, portables DML zu schreiben - PL / SQL unterscheidet sich grundlegend von T-SQL. Aus Gründen der Portabilität ist es einfacher, Ihre Datenbank über eine API von gespeicherten Prozeduren verfügbar zu machen. Die Signaturen dieser Prozeduren müssen auf beiden Plattformen identisch sein, die Implementierungen können jedoch proprietäre Funktionen verwenden - insgesamt ist dies viel einfacher als der Versuch, nur ANSI-Standard-SQL zu verwenden.

Diese Schlussfolgerung basiert auf mehrjähriger Erfahrung in der Entwicklung portabler Systeme, die sowohl mit Oracle als auch mit SQL Server arbeiten.