SQL Serverデータベース名にドットを入れても大丈夫ですか？

SQL Server（2005または2008）でドットを含むデータベース名（「MyApp.Sales」など）を使用すると、問題が発生しますか？

できますが、私はしません。[MyApp.Sales]などの角括弧でDB名を常にラップする必要があります。

要約すると、健全性を重視するなら、それをしないでください。

技術的に可能であっても、それは非常に悪い考えだと思います。

長年にわたって、4つの部分からなる命名規則を理解するのは難しいことですが、それはかなり明白なように思えますが、

server_name.database_name.schema_name.object_name

彼らがこのようなものを見たらどうなるか想像してみてください：

MAIN-SQL.[MyApp.Sales].hr.CompetitorsProducts

または：

[MAIN-SQL\EXPRESS].[MyApp.Sales].sch_HR.[Products From.Our-Competitors]

物事をシンプルに保つことが重要です。

他の誰かがこの質問に遭遇した場合...

ユーザーが混乱する可能性があるだけでなく、一部のツールが混乱する可能性があるため、これは悪い考えであることに留意してください。

マイクロソフト自体でさえこれに問題があります。Microsoft Queryを使用して（ODBC経由で）データベースをExcelシートに接続しようとすると、接続するデータベースを選択できる構成ウィザードが表示されます。ただし、ドットを含むデータベースを選択すると、サーバーが見つからなかったことを示すエラーが生成されます。ウィザードは値のエスケープが必要かどうかを確認せず、識別子を盲目的に連結しているようです。

もちろん回避策はありますが、最初からこれを行わないことにより、いくつかのトラブルを回避できます。

データベース名、パブリケーション名、ユーザー名にピリオドを使用しないでください。また、名前にピリオドを使用しないことを強くお勧めします（列、テーブル、ビュー、データベースなど）。

更新：マイナスのダッシュ「-」が同様の問題を引き起こすことを確認できます。

ここで何が起こるかです：

SQL Serverは、システムストアドプロシージャのような内部使用のためにスクリプトを使用します。既にここで述べたように、使用するコマンドは、名前を括弧に入れることを強制する場合があり、それは（真剣にmicrosoft？）ストアドプロシージャの使用に対して（常に）大丈夫ではありません。

実際、ストアドプロシージャはすべてのデータベースを反復処理し、データベース名を適切にエスケープしないため、放棄情報をクリーンアップすることはできません。このイテレーションは、8を超えるSPでパッチを適用することができなかった複雑なことです。

さらに、MMCまたはスクリプトを使用してレプリケーションの競合を編集することはできません。名前の中にドットを含む1つの（One！）データベースがある場合、これらの問題はeverey db、すべての出版物で発生します。

これらは私が持っている出来事です。複雑なSQLアクションはsql言語で処理され、ベースが適切であれば正常に機能します。

Microsoft Queryを使用して（ODBC経由で）データベースをExcelシートに接続しようとすると、接続するデータベースを選択できる構成ウィザードが表示されます。- AKZENT

これらのエラーはサードパーティのソフトウェアでより頻繁に見つかる可能性があるため、SQLサーバー上のあらゆる名前にドットを使用しないでください。

名前に使用できる文字は多数ありますが、慣習と常識により、特殊文字の使用が制限されています。「_」（アンダースコア）は実証済みの最も安全なセパレータであり、読みやすさを維持します。

同様に、外部キー名にはドットを含めないでください。

そのような名前の名前を変更する必要がある場合は、ブラケットを使用してsp_rename作業する必要があります（外部キーの名前を変更するため、スキーマを指定する必要があるため）。

例：

sp_rename '[MySchema].[MyFKName.With.Dots]' 'NewFKName' 'OBJECT'

大括弧を忘れると、エラーが発生します：15225

サプライヤの1つがスキーマ名[System.Activities.DurableInstancing]を導入することを選択しました。データロードツールが破損しているため、その奇妙さに対処するためにさらに開発を進めています。しないでください。使う '-'。