855

データベースを設計するときはいつでも、データベース内の項目に名前を付ける最良の方法があるかどうかを常に考えています。かなり頻繁に、私は次の質問を自問します。

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

データベース内の項目に名前を付けるための推奨ガイドラインはありますか?

4

23 に答える 23

362

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

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

  1. テーブルの単数形の名前
  2. 列の単数形の名前
  3. テーブルプレフィックスのスキーマ名（例：SchemeName.TableName）
  4. パスカルケーシング（別名アッパーキャメルケース）
于 2008-08-11T12:39:37.817 に答える
335

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

  1. 複数のテーブル名:私の好みは複数形です
  2. 単数の列名:はい
  3. 表または列の接頭辞:
  • テーブル: *通常* 接頭辞なしが最適です。
  • 列: いいえ。
  1. 項目の名前付けには大文字と小文字を区別しないでください:テーブルと列の両方に PascalCase を使用します。

詳細:

(1)しなければならないこと。毎回特定の方法で行わなければならない ことはほとんどありませんが、いくつかあります。

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

(2)おそらくあなたがすべきこと。

  • 異なるテーブルの同じ種類のデータを表すフィールドには、同じ名前を付ける必要があります。あるテーブルに Zip を配置し、別のテーブルに ZipCode を配置しないでください。
  • テーブル名または列名で単語を区切るには、PascalCasing を使用します。camelCasing を使用しても本質的に問題はありませんが、それは規則ではなく、おかしく見えます。アンダースコアについてはすぐに説明します。(昔のように ALLCAPS を使用することはできません。OBNOXIOUSTABLE.ANNOYING_COLUMN は 20 年前の DB2 では問題ありませんでしたが、現在は問題ありません。)
  • 単語を人為的に短縮または短縮しないでください。短くて紛らわしい名前よりも、長くて明確な名前の方が良い. 超短い名前は、より暗く、より野蛮な時代からの名残りです。Cus_AddRef. それは一体何ですか？保管宛先参照? 顧客の追加返金? カスタムアドレス紹介?

(3)考慮すべきこと。

  • テーブルには複数形の名前を付けるべきだと本当に思います。特異だと思う人もいます。他の場所で引数を読んでください。ただし、列名は単数形にする必要があります。複数のテーブル名を使用する場合でも、他のテーブルの組み合わせを表すテーブルは単数形になる場合があります。たとえば、PromotionsテーブルとItemsテーブルがある場合、プロモーションの一部であるアイテムを表すテーブルは Promotions_Items になる可能性がありますが、合法的に Promotion_Items になる可能性もあります (1 対多の関係を反映して)。
  • アンダースコアは一貫して、特定の目的のために使用してください。PascalCasing を使用すると、一般的なテーブル名だけで十分に明確になるはずです。単語を区切るためにアンダースコアは必要ありません。(a) 連想テーブルを示すため、または (b) 接頭辞としてアンダースコアを保存します。これについては、次の箇条書きで説明します。
  • プレフィックスは良いも悪いもありません。通常は最善ではありません。最初の 1 つか 2 つのデータベースでは、テーブルの一般的なテーマ別グループ化に接頭辞を使用することはお勧めしません。表はカテゴリに簡単に適合しなくなり、実際には表を見つけるのが難しくなる可能性があります. 経験を積めば、害よりも有益なプレフィックス スキームを計画して適用することができます。私は一度、データテーブルがtblで始まるデータベース、 ctblで始まる構成テーブル、vewで始まるビュー、proc のsp、および udf のfnで作業したことがあります、およびその他のいくつか。それは細心の注意を払って一貫して適用されたので、うまくいきました. プレフィックスが必要になるのは、何らかの理由で同じデータベースに存在する実際に個別のソリューションがある場合のみです。それらにプレフィックスを付けると、テーブルをグループ化するのに非常に役立ちます。目立たせたい一時テーブルなどの特別な状況では、プレフィックスも問題ありません。
  • 列にプレフィックスを付けたいと思うことはほとんどありません。
于 2010-01-22T16:07:18.463 に答える
106

わかりました、私たちは意見を検討しているので:

テーブル名は複数形であるべきだと思います。テーブルは、エンティティのコレクション (テーブル) です。各行は 1 つのエンティティを表し、表はコレクションを表します。したがって、Person エンティティのテーブルを People (または Person など、好きなように) と呼びます。

クエリで単数形の「エンティティ名」を見たい人のために、テーブル エイリアスを使用します。

SELECT person.Name
FROM People person

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

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

于 2008-08-11T10:49:03.687 に答える
78

私は3つのDBAを持つデータベースサポートチームで働いており、検討されているオプションは次のとおりです。

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

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

フィールドの場合、フィールド名にはテーブルのプレフィックス/ acryonm（つまり、cust_address1）が含まれていると予想されます。また、標準のサフィックスのセット（PKの場合は_id、「コード」の場合は_cd、「name」の場合は_nm）を使用することをお勧めします。 "、" number "の場合は_nb、" Date "の場合は_dt）。

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

すなわち

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

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

于 2008-08-11T12:24:17.647 に答える
53
  1. いいえ。テーブルは、それが表すエンティティにちなんで命名する必要があります。Person, not people は、レコードの 1 つが表す人を指す方法です。
  2. 繰り返しますが、同じことです。列 FirstName を FirstNames と呼ぶべきではありません。それはすべて、列で何を表現したいかによって異なります。
  3. 番号。
  4. はい。わかりやすくするためにケースに入れます。"FirstName" のような列が必要な場合は、大文字と小文字を区別すると読みやすくなります。

Ok。それは私の $0.02 です

于 2008-08-11T10:35:10.643 に答える
36

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

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

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

  3. テーブル名を単数形にすると、テーブルが表すクラス名と一致させることができます。繰り返しになりますが、これによりコードが簡素化され、テーブル名だけを使用してクラスをインスタンス化するなど、非常に巧妙なことを行うことができます。また、コードの一貫性が向上するため、...

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

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

于 2013-04-29T19:26:10.883 に答える
36

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

ウィキペディアのデータ要素名を参照してください。

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

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

于 2008-10-23T10:45:02.153 に答える
27

私たちの好み:

  1. テーブル名は複数形にするべきですか?
    一度もない。コレクションであることの引数は理にかなっていますが、テーブルに何が含まれるかはわかりません (0、1、または多数のアイテム)。複数の規則があると、命名が不必要に複雑になります。1 つの家、2 つの家、マウス対マウス、人対人、そして私たちは他の言語を見ていません。

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

  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 と合わせても意味があります。

    ただし、これらのほとんどは好みです。- 一貫性がある限り、誰が読んでも予測できるはずです。

于 2010-03-26T13:58:16.517 に答える
23

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

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

于 2008-08-11T13:13:58.747 に答える
17

私はこれがゲームに遅れていることを知っており、質問はすでに非常によく答えられていますが、列名のプレフィックスに関する＃3について意見を述べたいと思います.

すべての列には、それらが定義されているテーブルに固有のプレフィックスを付けて名前を付ける必要があります。

たとえば、テーブル "customer" と "address" が与えられた場合、それぞれ "cust" と "addr" のプレフィックスを使用してみましょう。「customer」には、「cust_id」、「cust_name」などが含まれます。「アドレス」には、「addr_id」、「addr_cust_id」（顧客への外部キー）、「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%';
于 2011-09-02T22:19:26.930 に答える
16

これらに関する私の意見は次のとおりです。

1) いいえ、テーブル名は単数形にする必要があります。

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

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

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

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

（マットが示唆するように）常にエイリアスを使用することでそれが解消されるかどうかはわかりません。

2) 1 つのプロパティのみを保持するため、特異である必要があります。

3) 列名があいまいな場合 (上記のように、両方に [Key] という列がある場合)、テーブルの名前 (またはそのエイリアス) でそれらを十分に区別できません。クエリをすばやく入力してシンプルにしたい - 接頭辞を使用すると、不要な複雑さが増します。

4) あなたが望むものは何でも、CapitalCase をお勧めします

これらのいずれについても、絶対的なガイドラインはないと思います。

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

于 2008-08-11T11:27:56.230 に答える
14

私の意見では：

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

しかし、それが言及されたように、どんな慣習も慣習がないよりはましです。どのように選択しても、将来の変更が同じ規則に従うように文書化してください。

于 2008-08-11T15:23:32.027 に答える
11

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

それに対する正しい答えはないので、少し時間をかけて (ただし、あまり時間をかけて) 独自の規則を選択し、-ここが重要な部分です-それを固守する必要があります。

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

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

  1. はい。テーブルは、レコード、教師、または俳優のグループなので、複数形です。
  2. はい。
  3. 私はそれらを使用しません。
  4. 私がより頻繁に使用するデータベースである Firebird では、すべてが大文字になっているので問題ありません。とにかく、私がプログラミングしているときは、releaseYearのように読みやすい方法で名前を書きます。
于 2008-08-11T11:14:11.937 に答える
11
  1. テーブル名は必ず単数形にし、人ではなく人にする
    1. こっちも一緒
    2. いいえ、テーブル (tbl_) またはユーザー ストア プロシージャ (usp_) を扱っているとさえ述べているひどいプレフィックスをいくつか見てきました。これにデータベース名が続きます... やらないでください！
    3. はい。私はすべてのテーブル名を PascalCase にする傾向があります
于 2008-08-11T11:24:50.823 に答える
9

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

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

これが私の答えです：

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

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

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

  • クライアントとソリューションドメインの言語を使用する
  • 説明的であること
  • 一貫性を保つ
  • 明確にし、反映し、リファクタリングする
  • すべての人に明確でない限り、略語を使用しないでください
  • SQL予約キーワードを列名として使用しないでください
于 2008-08-11T12:27:27.670 に答える
9 
SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName
于 2010-01-22T23:19:44.657 に答える
9

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

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

于 2008-10-22T17:05:31.713 に答える
5

テーブル名は一連のオブジェクトを表すため、常に単数形にする必要があります。群れとは羊の群れを指し、群れは鳥の群れを指します。複数形は必要ありません。テーブル名が 2 つの名前の合成であり、命名規則が複数形の場合、複数形の名前が最初の単語か 2 番目の単語か、またはその両方であるかを判断するのが難しくなります。それはロジックです。objects.instance ではなく、Object.instance です。または、TableNames.column(s) ではなく、TableName.column です。Microsoft SQL では大文字と小文字が区別されません。テーブル名が 2 つ以上の名前で構成されている場合にテーブル名または列名を区切るために大文字を使用すると、テーブル名が読みやすくなります。

于 2012-06-25T10:18:06.923 に答える
4

パーティーに非常に遅れましたが、それでも列プレフィックスについて2セントを追加したかった

列のtable_column（またはtableColumn）命名基準を使用することには、2つの主な議論があるようです。どちらも、列名自体がデータベース全体で一意であるという事実に基づいています。

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

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

私は両方の議論に欠陥があると思います。プレフィックスを使用せずに両方の問題を解決するのは簡単です。これが私の提案です：

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

table_columnの代わりにtable.columnを検索できるようになったため、明らかに2）が解決されます。

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

編集：はい、接頭辞を付けて列に名前を付けると正しい使用法が適用されることを認識していますが、私のアプローチはプログラマーに依存しています

于 2012-12-03T09:11:42.430 に答える
3

基本的なデータベースの命名規則 (およびスタイル) (詳細については、ここをクリックしてください)

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

于 2011-05-05T06:08:50.227 に答える
2

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

于 2011-06-26T19:18:57.333 に答える
-4 

--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. テーブル名と列名のパスカルケース、インデックスと制約のプレフィックス+すべてのキャップ。
于 2008-08-11T11:46:05.617 に答える