手書きのコードでSQL Serverのブラケット表記を使用するのは理にかなっていますか？

コードジェネレーターは[]、ほぼすべてに対して新しいMicrosoftブラケット表記（）を使用して出力を生成する場合、より単純になる傾向があります。

最初に見たとき、やや禁止された引用識別子表記法の生まれ変わりをすごいけど。

私の知る限り、Microsoft独自の拡張機能です（つまり、Oracleはサポートしていません）。

SQL Serverを見ると、次のようなテーブルを定義しても違いはありません。

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

または

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

それは個人的または企業スタイルの問題です。一貫してください。

データベースをOracleに移行する場合、括弧はオプションではありません。

古い引用識別子を使用できますが、これらは大文字と小文字を区別するため、多くの問題を引き起こします。

生成されたコードからすべてのブラケットを削除し、名前に空白、他の特殊文字、予約キーワードを使用することを避け、ほとんどのDBMSが理解できる方法でコードを作成することをお勧めしますか？

標準SQLは、引用"符付き識別子に二重引用符を使用します。SQL Serverは、QUOTED_IDENTIFIERオプション（ANSI_QUOTESmySQL内）を使用してこれをサポートします。標準SQLは一般に移植性を改善し、この場合はOracleに移植します。同様に私は（中級SQL-92の要件）大文字にSQLキーワードを変更し、拡大したいintにINTEGER（エントリレベルのSQL-92の要件）。

IMO、フレーバーが何であれ、引用識別子を不必要に使用しないでください。

これは主観的な問題ですが、不必要な括弧はペットのピートのリストの一番上にあります。「！=」のつづりを間違えるより少し面倒ですが、列リストの先頭のコンマほど悪くはありません。

客観的に言えば、括弧の目的を考慮してください。そうでない場合、オブジェクト名を許可します。その目的を考えると、括弧は最悪の場合はコードの匂いであり、せいぜい怠の兆候です。

• テーブルまたは列の名前が次の場合、括弧が必要です。

  • スペースを含む： SELECT [column name] FROM table;
  • ブラケットを含む：SELECT [wt[f]、またはSELECT [wt]]f]
  • 含まれている英数字以外の記号などを^か!（はい、彼らがすることができ、これらのシンボルを含みます！）
  • ある予約キーワードなどはKEY、STATE、RULE、...

  もちろん、スキーマを制御できる場合は、これらのような名前を使用しないでください。ただし、場合によっては、最適な名前は予約済みの名前（KEY汎用Key-Valueテーブルのキー列など）であるため、使用する度合いを決定するのはあなた次第です（したがって、どこでも引用する必要があります）。

  また、SSMSおよびVS DESCRIPTIONがSQL Serverによって予約されていないがそれらのツールにとって特別なキーワードを提供していることを示す青色の強調表示を抑制するために、括弧を使用します。

• SQLを動的に生成するときは、必ず括弧を使用してください。そのための簡単な方法QUOTENAME()は、動的に参照しているオブジェクトを呼び出すことです（例SELECT QUOTENAME(name) FROM sys.databases;）。sp_MSforeachdb、たとえば、これを行いません。

コードを生成するコードを書くとき、データベースオブジェクト名を角括弧で囲みます。手でコードを書くときは括弧を含めませんが、コードの可読性を損なうことがわかります。また、スペースを含むデータベースオブジェクト名を禁止します。SQL Serverでは、オブジェクト名にスペースを使用できますが、それが良いことを意味するわけではありません。

おそらく、ポータブルDDLを使用しようとさえしないでしょう。必要に応じて、SQL ServerのシステムビューからOracleテーブル定義を生成した方が良いでしょう。

ポータブルDMLを記述することも理にかなわないと思います-PL / SQLはT-SQLとはまったく異なります。移植性のために、ストアドプロシージャのAPIを介してデータベースを公開する方が簡単です。これらのプロシージャのシグネチャは両方のプラットフォームで同じでなければなりませんが、実装では独自の機能を使用できます。全体的には、ANSI標準SQLのみを使用するよりもはるかに簡単です。

この結論は、OracleとSQL Serverの両方で動作するポータブルシステムの開発における数年の経験に基づいています。