データベース、テーブル、列の命名規則？[閉まっている]

データベースを設計するときはいつでも、データベース内のアイテムに名前を付ける最善の方法があるかどうか常に疑問に思います。多くの場合、私は自分に次の質問をします。

1. テーブル名は複数にする必要がありますか？
2. 列名は単数である必要がありますか？
3. テーブルまたは列にプレフィックスを付ける必要がありますか？
4. アイテムの命名に大文字と小文字を使用する必要がありますか？

データベースのアイテムに名前を付けるための推奨ガイドラインはありますか？

MicrosoftのSQL Serverサンプルデータベースを確認することをお勧めします。https： //github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

AdventureWorksサンプルでは、​​データベースオブジェクトの編成にスキーマ名を使用する、非常に明確で一貫した命名規則を使用しています。

1. テーブルの単数形の名前
2. 列の単数形の名前
3. テーブルプレフィックスのスキーマ名（例：SchemeName.TableName）
4. パスカルケーシング（別名キャメルケース）

ここで遅い答えですが、要するに：

1. 私の好みは複数です
2. はい
3. テーブル：*通常*接頭辞は最適ではありません。 列：いいえ。
4. テーブルと列の両方：PascalCase。

詳細：

（1）あなたがしなければならないこと。毎回特定の方法で行う必要がある ことはほとんどありませんが、いくつかあります。

• 「[singularOfTableName] ID」形式を使用して主キーに名前を付けます。つまり、テーブル名がCustomerでもCustomersでも、主キーはCustomerIDである必要があります。
• さらに、外部キーは異なるテーブルで一貫して名前を付ける必要があります。これを行わない人を殴打することは合法であるべきです。定義された外部キー制約がしばしば重要である一方で、一貫した外部キ​​ーの命名が常に重要であると私は提出します
• データベースには内部規則が必要です。後のセクションで、私は非常に柔軟であることがわかりますが、データベース内では、ネーミングは非常に一貫している必要があります。顧客用のテーブルの名前をCustomersとするかCustomerとするかは、同じデータベース全体で同じように行うよりも重要ではありません。コインを裏返してアンダースコアの使用方法を決定することもできますが、同じように使用し続ける必要があります。これをしなければ、あなたは低い自尊心を持つべき悪い人です。

（2）何をすべきか。

• 異なるテーブルの同じ種類のデータを表すフィールドには、同じ名前を付ける必要があります。1つのテーブルにZipを設定し、別のテーブルにZipCodeを設定しないでください。
• テーブル名または列名の単語を区切るには、PascalCasingを使用します。camelCasingを使用しても本質的に問題はありませんが、それは慣例ではなく、面白​​そうです。アンダースコアについては後で説明します。（昔のようにALLCAPSを使用することはできません。OBNOXIOUSTABLE.ANNOYING_COLUMNは、20年前のDB2では大丈夫でしたが、現在では大丈夫です。）
• 人工的に単語を短くしたり、省略したりしないでください。名前は短くて混乱するよりも長くて明確である方が良いです。超短い名前は、より暗い、より野蛮な時代からのホールドオーバーです。Cus_AddRef。それは一体何ですか？保管宛先参照？顧客の追加払い戻し？カスタムアドレス紹介？

（3） 考慮すべきこと。

• テーブルには複数の名前を付ける必要があると思います。単数だと思う人もいます。他の場所で議論を読んでください。ただし、列名は単数形でなければなりません。複数のテーブル名を使用する場合でも、他のテーブルの組み合わせを表すテーブルは単数形になる場合があります。たとえば、プロモーションがある場合テーブルとItemsテーブルの一部であるアイテムを表すテーブルはPromotions_Itemsになる可能性がありますが、正当に考えると、1対多の関係を反映したPromotion_Itemsになる可能性もあります。
• アンダースコアは、一貫して特定の目的で使用してください。PascalCasingを使用すると、一般的なテーブル名だけで十分明確になります。単語を区切るためにアンダースコアは必要ありません。下線を保存して、（a）連想テーブルを示すか、（b）プレフィックスを付けます。これについては、次の箇条書きで説明します。
• プレフィックスは良いものでも悪いものでもありません。それは通常最善ではありません。最初の1つまたは2つでは、テーブルの一般的な主題別グループ化に接頭辞を使用することはお勧めしません。テーブルは最終的にカテゴリに適合しなくなり、実際にはテーブルを見つけにくくなる可能性があります。経験があれば、害よりも効果的な接頭辞スキームを計画して適用できます。私は、データテーブルが始まった場所を一度デシベルで働いていたTBLとテーブルを設定ファイル、CTBLと、ビューVEW、PROCのSP、およびUDFの FN、および他のいくつか。それは細心の注意を払って、一貫して適用されたので、大丈夫でした。接頭辞が必要になるのは、なんらかの理由で同じデータベースに常駐する本当に別のソリューションがある場合のみです。プレフィックスを付けると、テーブルをグループ化するのに非常に役立ちます。プレフィックスは、一時テーブルを目立たせたい場合など、特別な状況でも問題ありません。
• 列にプレフィックスを付けることはほとんどありません（あるとしても）。

OK、私たちは意見を検討しているので：

テーブル名は複数である必要があると思います。テーブルは、エンティティのコレクション（テーブル）です。各行は単一のエンティティを表し、テーブルはコレクションを表します。だから私はPersonエンティティのテーブルをPeople（またはPersons、あなたの好きなものは何でも）と呼びます。

クエリで単一の「エンティティ名」を確認したい場合は、テーブルエイリアスを次のように使用します。

SELECT person.Name
FROM People person

LINQの「from person in people select person.Name」に少し似ています。

2、3、4については、@ Larsに同意します。

私は3人のDBAがいるデータベースサポートチームで働いています。

1. 命名基準は、基準がない場合よりも優れています。
2. 「真の」標準はありません。私たち全員が好みを持っています
3. すでに標準がある場合は、それを使用します。別の標準を作成したり、既存の標準を濁らせたりしないでください。

テーブルには単数形の名前を使用します。テーブルには、システムの名前（またはその頭字語）が前に付けられる傾向があります。これは、プレフィックスを変更してテーブルを論理的にグループ化できるため（たとえば、reg_customer、reg_booking、およびregadmin_limits）、システムが複雑な場合に役立ちます。

フィールドの場合、フィールド名にはテーブルのプレフィックス/アクリオン（例：cust_address1）が含まれると想定し、標準のサフィックスセット（PKの場合は_id、 "code"の場合は_cd、 "nameの場合は_nm "、_nbは「数値」、_dtは「日付」）。

Foriegnキーフィールドの名前は、主キーフィールドと同じである必要があります。

すなわち

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

新しいプロジェクトを開発するときは、推奨されるエンティティ名、プレフィックス、頭字語をすべて書き出し、このドキュメントを開発者に提供することをお勧めします。その後、新しいテーブルを作成することを決定した場合、テーブルとフィールドの名前を「推測」するのではなく、ドキュメントを参照できます。

1. いいえ。テーブルは、それが表すエンティティに基づいて名前を付ける必要があります。人ではなく人が、レコードの1つが表す人をどのように参照するかです。
2. 繰り返しますが、同じことです。列FirstNameは、実際にはFirstNamesと呼ばれるべきではありません。それはすべて、列で何を表現するかによって異なります。
3. 番号。
4. はい。明確にするためにケースに入れてください。「FirstName」のような列が必要な場合は、大文字にすることで読みやすくなります。

OK。それは私の$ 0.02

ISO / IEC 11179スタイルの命名規則にも賛成です。これらは規範的というよりはガイドラインであることに注意してください。

Wikipediaのデータ要素名を参照してください。

「テーブルはエンティティのコレクションであり、コレクションの命名ガイドラインに従います。理想的には、集合的な名前が使用されます：例：Personnel。複数も正しい：Employees。不正な名前には、Employee、tblEmployee、およびEmployeeTableが含まれます。」

いつものように、ルールには例外があります。たとえば、常に正確に1行を持つテーブルは、構成テーブルなどの単一の名前の方が良い場合があります。そして、一貫性は最も重要です：あなたが買い物をするかどうかを確認し、そうであれば、それに従ってください。気に入らない場合は、唯一のレンジャーではなく、ビジネスケースを実行して変更してください。

テーブルが複数形であるかどうかはすべて個人的な好みの問題であり、ベストプラクティスは存在しないという議論は常に耳にします。特にDBAとは対照的に、プログラマーとしてはそうだとは思いません。私が知る限り、テーブル名を単数にすることによってコードに正当な利点がある一方で、「オブジェクトのコレクションだからこそ意味がある」以外にテーブル名を複数形にする正当な理由はありません。例えば：

1. 複数のあいまいさによるバグやミスを回避します。プログラマーはスペルの専門知識で正確に知られていないため、いくつかの単語を複数形にすると混乱を招きます。たとえば、複数形の単語は「es」または単に「s」で終わりますか？それは人ですか、それとも人ですか。大きなチームでプロジェクトに取り組むとき、これは問題になることがあります。たとえば、チームメンバーが間違ったメソッドを使用して、作成したテーブルを複数形にした場合です。このテーブルを操作するまでに、アクセスできないコードや修正に時間がかかりすぎるコード全体で使用されます。その結果、テーブルを使用するたびにスペルを間違えることを覚えておかなければなりません。これとよく似たことが私に起こりました。チームのすべてのメンバーが一貫して簡単に正確に使用できるようにするのは簡単です。エラーなしでテーブル名を修正するか、常にテーブル名を検索する必要がある方が良いでしょう。単一バージョンは、チーム環境での処理がはるかに簡単です。

2. テーブル名の単一バージョンを使用し、主キーの前にテーブル名を付けると、コードのみで主キーからテーブル名を簡単に決定できる、またはその逆の利点があります。テーブル名を含む変数を指定し、「Id」を最後に連結すると、追加のクエリを実行しなくても、コードを介してテーブルの主キーを取得できます。または、主キーの末尾から「Id」を切り取って、コードでテーブル名を決定できます。主キーのテーブル名なしで "id"を使用する場合、主キーからテーブル名をコードで判別することはできません。さらに、テーブル名を複数化し、PK列にテーブル名のプレフィックスを付けるほとんどの人は、PKでテーブル名の単数バージョンを使用します（たとえば、statusesおよびstatus_id）。

3. テーブル名を単数にすると、それらが表すクラス名と一致させることができます。繰り返しになりますが、これによりコードが単純化され、テーブル名のみを持つことでクラスをインスタンス化するなど、本当にきちんとしたことができるようになります。それはまたあなたのコードをより一貫性のあるものにするだけで、それは...につながります

4. テーブル名を単数にすると、命名体系が一貫し、整理され、すべての場所で維持しやすくなります。コード内のすべてのインスタンスで、列名、クラス名、テーブル名のいずれであっても、まったく同じ名前であることがわかります。これにより、グローバル検索を実行して、データが使用されているすべての場所を確認できます。テーブル名を複数形にすると、そのテーブル名の単数形（主キーで変換されるクラス）を使用する場合があります。データが複数形と呼ばれるインスタンスと単数形と呼ばれるインスタンスがないことは、理にかなっています。

要約すると、テーブル名を複数形にすると、コードをよりスマートで扱いやすくするためのあらゆる種類の利点が失われます。テーブル名をオブジェクトまたはローカルコード名に変換するためにルックアップテーブル/配列を使用しなければならない場合さえあります。単数形のテーブル名は、最初は少し変な感じがするかもしれませんが、複数形の名前に比べて大きな利点があり、ベストプラクティスだと思います。

私たちの好み：

1. テーブル名は複数にする必要がありますか？
   決して。それがコレクションであるという議論は理にかなっていますが、テーブルに何が含まれるか（0、1、または多くのアイテム）はわかりません。複数のルールにより、命名が不必要に複雑になります。1つの家、2つの家、ネズミとネズミ、人と人、そして私たちは他の言語も調べていません。

   Update person set property = 'value'テーブル内の各人に作用します。
   Select * from person where person.name = 'Greg'個人の行のコレクション/行セットを返します。

2. 列名は単数である必要がありますか？
   通常、はい。ただし、正規化ルールに違反している場合を除きます。

3. テーブルまたは列にプレフィックスを付ける必要がありますか？
   主にプラットフォームの設定。列の前にテーブル名を付けることをお勧めします。テーブルにはプレフィックスを付けませんが、ビュー（v_）とstored_procedures（sp_またはf_（関数））にプレフィックスを付けます。これは、実際にはビューの計算フィールドであるv_person.ageを更新しようとする人に役立ちます（とにかく更新できません）。

   また、キーワードの衝突を回避するための優れた方法です（delivery.fromは中断しますが、delivery_fromは中断しません）。

   それはコードをより冗長にしますが、多くの場合読みやすさを助けます。

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ...は非常に読みやすく明示的です。ただし、これは手に負えなくなる可能性があります。

   customer.customer_customer_type_id

   はcustomerとcustomer_typeテーブルの関係を示し、customer_typeテーブル（customer_type_id）の主キーを示します。クエリをデバッグしているときに 'customer_customer_type_id'が表示された場合は、（customerテーブル）の場所がすぐにわかります。

   または、customer_typeとcustomer_categoryの間にMM関係がある場合（特定のカテゴリでは特定のタイプのみが使用可能）

   customer_category_customer_type_id

   ...は長い（！）です。

4. アイテムの命名に大文字と小文字を使用する必要がありますか？はい-小文字:)、下線付き。これらは非常に読みやすく、クロスプラットフォームです。上記の3と組み合わせることも意味があります。

   これらのほとんどは設定ですが。-あなたが首尾一貫している限り、それを読む必要がある人は誰でも予測できるはずです。

ISO 11179-5：命名と識別の原則をご覧ください。こちらから入手できます：http ://metadata-standards.org/11179/#11179-5

私はしばらくここにブログを書きました：ISO-11179命名規則

私はこれがゲームに遅れていることを知っており、質問はすでに非常によく回答されていますが、列名の接頭辞に関する＃3についての私の意見を提供したいと思います。

すべての列には、それらが定義されているテーブルに固有の接頭辞を付けた名前にする必要があります。

たとえば、「customer」と「address」というテーブルがある場合、それぞれ「cust」と「addr」の接頭辞から始めましょう。「customer」には「cust_id」、「cust_name」などが含まれます。「address」には、「addr_id」、「addr_cust_id」（お客様にFKで返信）、「addr_street」などが含まれます。

私が最初にこの標準を提示されたとき、私はそれに対して完全に不満でした。私はその考えを嫌っていました。余分なタイピングと冗長性のすべてのアイデアに我慢できませんでした。今では、二度と戻れないほどの十分な経験があります。

これを実行すると、データベーススキーマのすべての列が一意になります。これには大きな利点が1つあります。これは、（もちろん、私の意見では）それに対するすべての議論よりも優先されます。

コードベース全体を検索して、特定の列に接触するコードのすべての行を確実に見つけることができます。

＃1のメリットは非常に大きいです。列を非推奨にし、列をスキーマから安全に削除する前に更新する必要があるファイルを正確に知ることができます。列の意味を変更して、リファクタリングする必要があるコードを正確に知ることができます。または、列のデータがシステムの特定の部分で使用されているかどうかを簡単に確認できます。これにより潜在的に巨大なプロジェクトが単純なプロジェクトに変わった回数や、開発作業で節約した時間を数えることはできません。

比較的マイナーなもう1つのメリットは、自己結合を行うときにテーブルエイリアスを使用するだけでよいことです。

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

これらについての私の意見は次のとおりです。

1）いいえ、テーブル名は単数形でなければなりません。

単純な選択（select * from Orders）には意味があるように見えますが、オブジェクト指向の同等物（Orders x = new Orders）にはあまり意味がありません。

DBのテーブルは、実際にはそのエンティティのセットです。set-logicを使用すると、より理にかなっています。

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

最後の行、結合の実際のロジックは、複数のテーブル名と混同しているように見えます。

（Mattが示唆するように）常にエイリアスを使用することでそれが明らかになるかどうかはわかりません。

2）1つのプロパティのみを保持するため、それらは単一である必要があります

3）決して、列名があいまいな場合（上記のように両方に[Key]と呼ばれる列がある場合）、テーブルの名前（またはそのエイリアス）で十分に区別できます。クエリをすばやく入力してシンプルにしたい-プレフィックスは不要な複雑さを追加します。

4）あなたが望むものは何でも、私はCapitalCaseを提案します

これらについて絶対的なガイドラインが1セットあるとは思いません。

選択したものがアプリケーションまたはDB全体で一貫している限り、それは本当に重要だとは思いません。

私の考えでは：

1. テーブル名は複数にする必要があります。
2. 列名は単数である必要があります。
3. 番号。
4. テーブル名と列名の両方について、CamelCase（私の好み）またはunderscore_separatedのいずれか。

ただし、これまでに説明したように、どの慣習も、何もしないよりはましです。どのように選択した場合でも、将来の変更が同じ規則に従うように文書化してください。

これらの各質問に対する最良の答えは、あなたとあなたのチームによって与えられると思います。命名規則を持つことは、命名規則がいかに正確であるかよりもはるかに重要です。

これに対する正しい答えはないので、少し時間をかけて（ただし、それほど多くはありません）、独自の規則を選択し、ここで重要な部分を守ってください。

もちろん、標準に関するいくつかの情報を求めることは良いことです。それはあなたが求めていることですが、あなたが得るかもしれないさまざまな答えの数について心配したり心配したりしないでください。あなたにとってより良いと思われる答えを選んでください。

念のため、ここに私の答えがあります：

1. はい。テーブルはレコード、教師、俳優のグループなので、複数形です。
2. はい。
3. 私はそれらを使用しません。
4. 私がより頻繁に使用するデータベース-Firebird-はすべてを大文字で保持するため、問題ではありません。とにかく、プログラミングするときは、releaseYearのように、読みやすい方法で名前を書きます。

1. 人ではなくテーブル名を必ず1つにしてください
   2. こっちも一緒
   3. いいえ、私はいくつかの恐ろしいプレフィックスを見てきました。扱っているのはテーブル（tbl_）またはユーザーストアプロシージャ（usp_）であると述べているところまでです。この後にデータベース名が続きます...しないでください！
   4. はい。私はすべてのテーブル名をPascalCaseする傾向があります

命名規則により、開発チームはプロジェクトの中心にある発見可能性と保守容易性を設計できます。

良い命名規則は進化するのに時間がかかりますが、それが整ったら、チームは共通の言語で前進することができます。良い命名規則は、プロジェクトとともに有機的に成長します。優れた命名規則は、ソフトウェアライフサイクルの最も長く、最も重要なフェーズ、つまり本番環境でのサービス管理における変化に簡単に対処します。

これが私の答えです：

1. はい。テーブル名は、たとえば一連のトレード、証券、またはカウンターパーティを指す場合、複数形にする必要があります。
2. はい。
3. はい。SQLテーブルにはプレフィックスtb_、ビューにはプレフィックスvw_、ストアドプロシージャにはプレフィックスusp_、トリガーにはプレフィックスtg_の後にデータベース名が続きます。
4. 列名は、アンダースコアで区切られた小文字でなければなりません。

名前の付け方は難しいですが、すべての組織で名前を付けることができる人がいます。すべてのソフトウェアチームで、名前付けの標準に責任を持ち、sec_id、sec_value、およびsecurity_idなどの名前付けの問題がプロジェクトに組み込まれる前に確実に解決されるようにする必要があります。 。

それで、良い命名規則と標準の基本的な信条は何ですか？-

• クライアントの言語とソリューションドメインを使用する
• 説明的であること
• 一貫している
• 明確化、反映、リファクタリング
• 誰にでも明らかな場合を除き、略語は使用しないでください
• SQL予約キーワードを列名として使用しないでください

ここにいくつかの選択肢を提供するリンクがあります。部分的に定義された仕様に依存する必要はなく、従うことができる単純な仕様を探していました。

http://justinsomnia.org/writings/naming_conventions.html

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

テーブル名はオブジェクトのセットを表すため、常に単数形にする必要があります。あなたが羊のグループを指定するために群れを言うように、または群れは鳥のグループを指定します。複数である必要はありません。テーブル名が2つの名前の組み合わせであり、命名規則が複数である場合、複数の名前が最初の単語であるか2番目の単語であるか、またはその両方であるかがわかりにくくなります。それは論理です。objects.instanceではなく、Object.instanceです。または、TableNames.column（s）ではなく、TableName.column。Microsoft SQLは大文字と小文字を区別しません。大文字を使用すると、2つ以上の名前で構成されるテーブルまたは列の名前を分離して、テーブル名を読みやすくなります。

テーブル名：単数であるオブジェクトではなく、実世界のオブジェクトを表す単一のエンティティであるため、単数である必要があります。

列名：単数である必要があり、それが原子値を保持し、正規化理論を裏付けることを伝えます。ただし、同じタイプのプロパティがn個ある場合は、1、2、...、nなどの接尾辞を付ける必要があります。

テーブル/列のプレフィックス：これは大きなトピックです。後で説明します。

ケース：キャメルケースである必要があります

私の友人、パトリックカーチャー、私はあなたが書いたように、誰かに不快になる可能性のあるものは書かないでくださいようお願いします。これを行う。"。私は友人のパトリックにこの間違いをしたことは一度もありませんが、一般的に書いています。彼らが一緒にこれのためにあなたを倒すつもりならどうしますか？:)

パーティーには遅刻しましたが、列のプレフィックスについて2セント追加したかったのです。

列名自体がデータベース全体で一意であるという事実に基づいて、列のtable_column（またはtableColumn）命名標準を使用するための2つの主要な引数があるようです。

1）クエリで常にテーブル名や列エイリアスを指定する必要はありません

2）列名のコード全体を簡単に検索できます

どちらの主張にも欠陥があると思います。接頭辞を使用せずに両方の問題を解決するのは簡単です。これが私の提案です：

SQLでは常にテーブル名を使用してください。たとえば、常にcolumnではなくtable.columnを使用します。

これは明らかに2）を解決します。table_columnではなくtable.columnを検索するだけです。

しかし、私はあなたが悲鳴を上げるのを聞くことができます、それはどのように解決します1）？それはまさにこれを回避することでした。はい、そうでしたが、ソリューションにはひどく欠陥がありました。どうして？さて、プレフィックスソリューションは次の
ようになります。あいまいな場合にtable.columnを指定する必要をなくすには、すべての列にtable_columnという名前を付けます。
ただし、これは、今後、常に列を指定するたびに列名を記述する必要があることを意味します。しかし、とにかくそれを行う必要がある場合、常に明示的にtable.columnを作成するよりもどのような利点がありますか？正確には、メリットはありません。入力する文字数とまったく同じです。

編集：はい、私は列にプレフィックスを付けると正しい使用法が適用されることを知っていますが、私のアプローチはプログラマーに依存しています

必須のデータベース命名規則（およびスタイル）（詳細については、ここをクリックしてください）

テーブル名は、短く明確な名前を選択し、1つまたは2つの単語を使用してテーブルを区別することにより、一意のフィールド名の命名が容易になります。また、ルックアップテーブルとリンクテーブルは、テーブルを単数形にし、複数形にすることはできません（更新：与えられた理由に同意この規則では、ほとんどの人は複数のテーブル名が本当に好きなので、私のスタンスを和らげました）...上記のリンクに従ってください

テーブル名は単数です。たとえば、誰かとその住所の間の関係をモデル化していたとしましょう。たとえば、データモデルを読んでいる場合は、「各人が0、1、または多くの住所に住んでいる可能性がある」ことを好みます。または「各人は0、1、または多くの住所に住んでいる可能性があります。」人を人として言い換えるよりも、住所を複数形にする方が簡単だと思います。さらに、集合名詞は、単数形とはかなり異なることがよくあります。

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

これらは私が教えられた慣習ですが、開発用ホースが使用するものなら何にでも適応する必要があります。

1. 複数。エンティティのコレクションです。
2. はい。属性は、エンティティの特異なプロパティの表現です。
3. はい、プレフィックステーブル名を使用すると、すべての制約インデックスとテーブルエイリアスの名前を簡単に追跡できます。
4. テーブル名と列名のパスカルケース、インデックスと制約のプレフィックス+ ALLキャップ。