データベースの世界では、普遍的に合意されていることがいくつかあります。 RAMの増加は、DMBSシステムにとって非常に有益です。 RAID上でデータとログファイルを分散すると、パフォーマンスが向上します。
命名規則はそれらの1つではありません。
これは驚くほど二極化したトピックであり、さまざまな方法論の支持者が彼らの立場にしっかりと定着しています。そして、同じものを守るために非常に声高で情熱的です。
この記事では、それぞれの点について合理的な結論を提示することを試みながら、特定の慣習と両側の議論のいくつかを掘り下げます。
大規模な複数化の議論
基本的に、これは単純なトピックです。たとえば、リレーショナルデータベーススキーマに顧客情報を含むテーブルに名前を付ける正しい方法は何ですか？ Customerですか またはCustomer ？
双方の議論がたくさんあります。
一見 、複数形のオブジェクトのコレクションを考えるのは自然なことです。複数の個人または企業のグループは顧客になります 。したがって、テーブル（オブジェクトのコレクション）には複数形で名前を付ける必要があります。そのテーブルの個々の行は、単一の顧客になります。 。
ISO / IECの命名原則は、時代遅れですが、複数形のテーブル名と単数形の列名を推奨しています。
ほとんどのSQLServerシステムテーブルは複数の名前を使用します（ sysnotifications 、 sysoperators ）、しかしこれは一貫性がありません。なぜsysproxylogin sysproxyloginsではありません ？
複数のテーブル名の引数では、テーブル内の行も全体の「インスタンス」として参照されます。これは、コレクション内のアイテムと同様です。 お客様 セット全体を定義します。単一の顧客 顧客のインスタンスです 。
逆に、単一のオブジェクト名を使用する理由はたくさんあります。
多くのアイテム（または顧客）が存在する可能性がありますが ）テーブルでは、テーブル自体を単一のエンティティと見なすことができます。顧客の箱は、内部に多数の顧客がいる場合でも、「顧客の箱」ではありません。さらに、テーブル内にアイテムが1つしかない場合もあれば、まったくない場合もあり、「顧客」の誤称になります。
単語のバリエーションに基づいてテーブル名を変更することを選択した場合、不整合がすぐに発生する可能性があります。多くの言葉は簡単ですが（顧客 顧客になります 、製品 製品になります ）、他の言葉はそうではないかもしれません。この場合、人 人になる可能性があります または人;特異なムース 複数形のムースと同じように見えます 。 （なぜムースのテーブルが必要なのですか？） People.FirstNameなどの規則 紛らわしいほど不明瞭になり始めます。
複数の言語が関係している場合、状況はさらに悪化します。単語の複数形は非常に多くの方法で変化する可能性があるため（顧客、マウス、ムース、子供、危機、シラバス、航空機）、非ネイティブスピーカーには追加の課題があります。単一のオブジェクト名を使用することで、この問題を完全に回避できます。
ケースコンベンションの質問
大文字小文字の区別には複数形の場合と同じ熱意はありませんが、いくつかの異なるオプションについて議論が行われます。それらには以下が含まれます：
- パスカルケース ：
CustomerOrderのように、連結された各単語の最初の文字は大文字になります。 -
キャメルケース ：最初の単語の最初の文字は小文字です。
customerOrderのように、後続のすべての連結単語には、大文字の最初の文字が含まれます。パスカルケースはキャメルケースのサブタイプと見なされることもありますが、Microsoftは通常この2つを区別しています。
3文字未満の単語の場合、
UIのように、大文字のみを使用することをお勧めします またはIO。 - アンダースコア[「C」ケース] ：
Customer_Orderのように、単語はアンダースコアで区切られます 、またはcustomer_Order–さらに多くの決定！
ジョンズホプキンス大学の研究者は、オブジェクト名のプログラミングにアンダースコアを使用する効率について調査を行いました。彼らは、キャメルケース（またはパスカルケース）を使用すると、タイピングの精度と認識が向上することを発見しました。アンダースコアはCプログラミングで広く使用されていましたが、最近はMicrosoftおよびJavaスタイルの言語に重点が置かれているCamel /PascalCaseに向かう傾向があります。
他のトピックと同様に、次の 確立された規則は、選択よりも重要です 大会自体の。
ここでの追加の考慮事項は、データベースの大文字と小文字の区別です。 SQL Serverの照合では、照合名に「CS」（大文字と小文字を区別）または「CI」（大文字と小文字を区別しない）を使用して、この機密性を判断します。例：
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive
SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
大文字と小文字を区別する照合では、Select * from myTable オブジェクトMyTable 。これにより、混乱を防ぐためにアンダースコアがわずかに望ましい場合がありますが、Intellisenseは、ほとんどの最新のプログラミング環境での入力ミスの排除にも役立ちます。
その他の命名規則に関する考慮事項
単数形と複数形の討論と大事件の質問は、戦いが最も激しい場所かもしれませんが、命名規則を検討する際に留意すべき領域が少なくとも3つあります。
SQLServerの予約語をオブジェクト名として使用しないでください。 これには、テーブルと列の両方が含まれます。例–ユーザー 、時間 、および日付 予約されています。予約されたキーワードは、呼び出し元のアプリケーションによっては、参照するために追加の注意が必要になる場合があります（角かっこを使用するなど）。これはスペースにも当てはまります。オブジェクト名のスペースを参照するには、引用符が必要です。
これは、別の推奨事項である精度とも関連しています。 System.CreateDate System.Dateよりもはるかに明確です 。適切に設計されたモデルにより、視聴者は基礎となるオブジェクトの目的をすぐに理解できます。識別子を外部キーとして参照する場合は、名前を自由に指定してください– Customer.CustomerID Customer.IDではなく 。
テーブルとビューのプレフィックスとサフィックスは避けてください 、tblTable 。ハンガリアン記法（常に変数の使用法を識別することを目的としていました）は、一般的なSQL Serverの命名規則に組み込まれましたが、広く無視されています。オブジェクト識別子は、オブジェクト自体ではなく、中に含まれるものを説明する必要があります。
ただし、プレフィックスはSQLServerサポートオブジェクトで役立ちます 、オブジェクトの機能的性質を説明しているため。
以下は、SQLServerオブジェクトで一般的に受け入れられているプレフィックスです。
- IX：インデックス
- PK：主キー
- FK：外部キー
- CK：チェック制約
- DF：デフォルト
- UQは一意のインデックスにも使用されることがあります。
このモデルは、上記で定義されたポイントを示しています。データの性質についての説明は必要ありません。単一の命名規則が使用され、明確な識別子が設定されています。
結局、コンベンションの命名論争の両側には長所と短所があります。ただし、双方が合意できる重要なポイントが1つあります。それは、行われた決定に関係なく、選択した規則に準拠することです。
どのSQL命名規則を使用し、その理由は何ですか？