データベーステーブルのID列の名前付け

データベーステーブルのID列の名前付けに関する人々の意見を知りたくありませんでした。

ID列の主キーを持つInvoicesというテーブルがある場合、他のテーブルと競合しないようにその列をInvoiceIDと呼び、それが何であるかを明らかにします。

私が現在作業している場所では、すべてのID列をIDと呼んでいます。

したがって、彼らは次のことを行います：

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

今、私はここにいくつかの問題を参照してください：
1.選択した上で、別名に列を必要とする
InvoiceIDは私の脳内に収まらない2. ID =
あなたがテーブルに別名なかったとInvoiceID言及した場合3.は、どのようなテーブル、それは明らかですついてる？

トピックに関する他の人々の考えは何ですか？

IDはSQLアンチパターンです。http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+aを参照してください

IDがIDのテーブルが多数ある場合は、レポートを作成するのがはるかに難しくなります。意味がわかりにくくなり、複雑なクエリが読みにくくなるだけでなく、エイリアスを使用してレポート自体を区別する必要があります。

さらに、誰かが利用可能なデータベースで自然結合を使用するほど愚かである場合、誤ったレコードに結合します。

一部のデータベースで許可されているUSING構文を使用する場合は、IDを使用することはできません。

IDを使用している場合、結合構文をコピーしていて（誰もこれを行ったことがないことを知らせないでください！）、結合条件のエイリアスを変更するのを忘れると、結合が誤って終了する可能性があります。

だからあなたは今持っています

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

あなたが意味したとき

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

idnameフィールドとしてtablenameIDを使用すると、この種の偶発的な間違いが発生する可能性がはるかに低くなり、見つけやすくなります。

私は常にid列にTableName + IDよりもIDを優先し、次に外部キーにTableName + IDを優先しました。これにより、すべてのテーブルのidフィールドの名前が同じになり、冗長な説明がなくなります。すべてのテーブルが同じ主キーフィールド名を持っているので、これは私には簡単に思えます。

テーブルを結合し、どのIdフィールドがどのテーブルに属しているのかわからない限り、私の意見では、この状況を処理するためにクエリを作成する必要があります。私が作業している場所では、ステートメントで使用するフィールドの前に常にテーブル/テーブルのエイリアスを付けています。

最近の私の会社では、まさにこれについてオタクの戦いがありました。LINQの登場により、冗長なテーブル名とIDのパターンが私の目にはさらにばかげています。FKを区別するためにテーブル名を指定する必要があるような方法でSQLを手書きしている場合、最も合理的な人は、タイピングの節約になるだけでなく、使用するSQLに明快さを追加すると言うでしょうPKとFKが明確にわかるID 。

例えば

FROM Employees e LEFT JOIN Customers c ON e.ID = c.EmployeeID

2つがリンクされているだけでなく、どちらがPKでどちらがFKであるかがわかります。一方、古いスタイルでは、見栄えがするか、名前が付けられていることを期待する必要があります。

私たちは使用しますがInvoiceID、使用しませんID。これにより、クエリが読みやすくなります。ID単独で表示した場合、特にテーブルにのエイリアスを設定した場合は、意味がある可能性がありますi。

テーブルのPKは単にIdでなければならず、外部キーはOtherTable + Idをリストする必要があることを、Kevenとここの他の数人に同意します。

しかし、私は最近、この議論をより重視した理由を1つ付け加えたいと思います。

私の現在の立場では、POCO生成を使用してエンティティフレームワークを採用しています。Idの標準の命名規則を使用すると、PKは、一連の共通の列名を共有するテーブルの検証などを備えた基本pocoクラスの継承を可能にします。これらの各テーブルのPKとしてTablename + Idを使用すると、これらのベースクラスを使用できなくなります。

思考のためのほんの一部の食べ物。

私の設定は、主キーのIDと外部キーのTableNameIDでもあります。また、エントリのユーザーが読み取り可能な識別子（つまり、名前:-)）を保持するほとんどのテーブルに、列「名前」が必要です。この構造はアプリケーション自体に大きな柔軟性を提供し、同じ方法でテーブルをまとめて処理できます。これは非常に強力なことです。通常、OOソフトウェアはデータベースの上に構築されますが、データベース自体が許可していないため、OOツールセットは適用できません。列のidとnameを使用することは、まだあまり良い方法ではありませんが、一歩です。

請求書からi.ID、il.IDを選択しますi左の結合InvoiceLines il on i.ID = il.InvoiceID

なぜこれができないのですか？

Select  
    Invoices.ID 
,   InvoiceLines.ID 
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

私の意見では、これは非常に読みやすくシンプルです。変数にiとilの名前を付けることは、一般的に不適切な選択です。

それほど重要ではありません。すべての命名規則で同様の問題が発生する可能性があります。

ただし、クエリを作成するたびにテーブル定義を確認する必要がないように、一貫性を保つことが重要です。

（コアテーブルで、外部キーのTableNameIDによって参照される） "ID"のみを使用する場所で作業を開始したばかりで、それによって直接発生する2つの運用上の問題が既に見つかりました。

あるケースでは、クエリは "... where ID in（SELECT ID FROM OtherTable ..."ではなく "... where ID in（SELECT TransID FROM OtherTable ..."の代わりに使用しました。

誰かが正直に言って、誤ったステートメントが「... where TransID in（SELECT OtherTableID from OtherTable ...」と読んだところに完全で一貫した名前が使用されていれば、それを見つけるのははるかに容易ではなかったでしょうか？私は思いませんそう。

もう1つの問題は、コードをリファクタリングするときに発生します。以前はクエリがコアテーブルから外れていたのに一時テーブルを使用した場合、古いコードは "... dbo.MyFunction（t.ID）..."を読み取り、それが変更されていないが "t"がコアテーブルの代わりに一時テーブルを使用すると、エラーは発生せず、誤った結果が返されます。

不必要なエラーを生成することが目標である場合（たぶん、十分な作業がない人もいます）、この種の命名規則は素晴らしいです。それ以外の場合は、一貫した名前を付けるのがよいでしょう。

簡単にするために、ほとんどの人はテーブルIDの列に名前を付けます。別のテーブルに外部キー参照がある場合、結合の場合は（例を使用するために）明示的にInvoiceIDと呼びますが、とにかくテーブルにエイリアスを設定しているため、明示的なinv.IDはinv.InvoiceIDよりも簡単です。

私は個人的に（それが前述されたように）好むTable.IDをするためにPKとTABLEIDのためのFK。（私を撃たないでください）Microsoft Accessでもこれをお勧めします。

ただし、一部の生成ツールはPKのTableIDを優先するという事実も知っています。これは、IDを含む単語に「ID」を含むすべての列名をリンクする傾向があるためです。

クエリデザイナーでもMicrosoft SQL Serverでこれを実行します（作成するクエリごとに、列IDのすべてのテーブルで新しく作成された不要なリレーションシップをすべて取り除きます）

THUS私の内部OCDが嫌いなのと同じように、私はTableIDの規則に従ってロールします。それがData BASEと呼ばれることを覚えておいてください。これは、多くの多くのアプリケーションが登場することを期待しています。そして、すべてのテクノロジーは、明確に記述されたスキーマで十分に正規化された恩恵を受けるはずです。

言うまでもなく、人々がTableNameやTableDescriptionなどを使い始めたら線を引きます。私の意見では、条約は次のことを行うべきです。

• テーブル名：複数。例 従業員

• テーブルエイリアス：完全なテーブル名、単数化。例

  SELECT Employee.*, eMail.Address
  FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well

[更新]

また、「関係の種類」または役割が原因で列が重複していることについて、このスレッドにはいくつかの有効な投稿があります。たとえば、ストアにEmployeeIDがある場合、スクワットが通知されます。だから私は時々Store.EmployeeID_Managerのようなことをします。確かに少し大きくなりますが、テーブルManagerIDやEmployeeIDがそこで何をしているのかを見つけようとする人が少なくないでしょう。クエリがWHEREの場合、次のように簡略化します。SELECT EmployeeID_Manager as ManagerID FROM Store

正式なデータディクショナリの観点からここに来て、データ要素に名前を付けますinvoice_ID。一般に、データ要素名はデータディクショナリ内で一意であり、理想的には同じ名前が付けられますemployee_IDが、コンテキストに基づいて追加の修飾語句が必要になる場合があります。たとえば、指定されたデータ要素は組織図で2回使用され、したがって次のように修飾されます。supervisor_employee_IDとsubordinate_employee_IDそれぞれ。

明らかに、命名規則は主観的であり、スタイルの問題です。ISO / IEC 11179ガイドラインが出発点として役立つと思います。

DBMSの場合、テーブルをエンティティのコレクションとして表示します（cofigテーブル、定数のテーブルなど、1行しか含まないものを除く）。たとえば、my employee_IDがキーであるテーブルの名前はになりますPersonnel。だから、すぐにこのTableNameID条約は私には役に立たない。

TableName.ID=PK TableNameID=FK大規模なデータモデルで使用されているスタイルを見て、少し混乱していることに気づかなければなりません。識別子の名前は全体を通して同じである、つまり、表示されるテーブルに基づいて名前が変更されないことを望みます。上記のスタイルは、外部キーの自然キーと複合キーを排除しながら、IDENTITY（自動インクリメント）列をすべてのテーブルに追加するショップで使用されているようです。これらのショップは、正式なデータディクショナリを持たず、データモデルから構築しない傾向があります。繰り返しますが、これは単にスタイルの問題であり、私が個人的にサブスクライブしないものです。結局のところ、それは私のためではありません。

私は、テーブルの名前が名前の要素を、たとえばそのようにするためのコンテキストを提供する場合、時には列名から修飾子を落とすためのケースを見ることができる、と述べているすべてemployee_last_name単純になる可能性last_nameにPersonnelテーブル。ここでの理論的根拠は、ドメインが「人の姓」で、より多くの可能性が高いとされていることであるUNIONとエドlast_nameの列から他のテーブルではなく、外部キーとして使用することで、別のテーブルが、その後、再び...私はちょうど私の心を変えるかもしれません時々あなたは言うことができない。つまり、データモデリングはアートであり、サイエンスでもあります。

一貫している限り、「ID」には何でも使用できると思います。テーブル名を含めることは重要です。Erwinのようなモデリングツールを使用して、命名規則と標準を適用することをお勧めします。クエリを記述するときに、テーブル間に存在する可能性のある関係を簡単に理解できます。

最初のステートメントの意味は、IDの代わりに「recno」のようなものを使用できるということです。したがって、このテーブルのPKはinvoice_recnoなどになります。

乾杯、ベン

私の投票は、テーブルIDのInvoiceIDです。また、外部キーとして使用する場合も同じ命名規則を使用し、クエリでインテリジェントなエイリアス名を使用します。

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

もちろん、他の例よりも長くなっています。しかし笑顔。これは後世のためであり、いつの日か、一部の貧しいジュニアコーダーがあなたの傑作を変える必要があるでしょう。この例ではあいまいさはなく、クエリにテーブルが追加されるので、冗長性に感謝します。

データベースの列名には「InvoiceID」を使用します。

LINQを介して名前のない構造体にフィールドをコピーする場合、構造体で唯一のIDであれば、そこに "ID"という名前を付けることができます。

列が外部キーで使用されず、編集または削除のために行を一意に識別するためだけに使用される場合は、「PK」という名前を付けます。

各キーに「invoices.id」ではなく「invoices.invoice_id」などの一意の名前を付けると、心配することなく「自然結合」および「使用」演算子を使用できます。例えば

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

の代わりに

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

SQLは、冗長にせずに十分冗長です。

（テーブルにIDとして使用される単一列の主キーがある）自分で一貫性を保つために私が行うことは、テーブルの主キーに名前を付けることTable_pkです。そのテーブルの主キーを指す外部キーがある場合はどこでも、列を呼び出しますPrimaryKeyTable_fk。そうすればCustomer_pk、CustomerテーブルとCustomer_fkOrderテーブルにa がある場合、OrderテーブルがCustomerテーブルのエントリを参照していることがわかります。

私にとって、これは読みやすいと思う結合では特に意味があります。

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk

FWIW、私たちの新しい標準（変更、ええと、つまり、すべての新しいプロジェクトで "進化する"を意味します）は次のとおりです。

• 小文字のデータベースフィールド名
• 大文字のテーブル名
• 下線を使用してフィールド名の単語を区切ります-コードでこれらをPascalの大文字に変換します。
• pk_ 接頭辞は主キーを意味します
• _id 接尾辞は整数の自動インクリメントIDを意味します
• fk_ プレフィックスは外部キーを意味します（サフィックスは不要）
• _VW ビューのサフィックス
• is_ ブールの接頭辞

したがって、NAMESという名前のテーブルには、フィールドpk_name_id, first_name, last_name, is_alive,とfk_companyビューがありLIVING_CUSTOMERS_VW、次のように定義されています。

SELECT first_name、last_name
CONTACT.NAMESから
WHERE（is_alive = 'True'）

他の人が言ったように、それが一貫していて、あなたの意味を不必要に不明瞭にしない限り、どんなスキームでもうまくいきます。

IDフィールド名にテーブル名を含めることに私は間違いなく同意します。あなたが与える理由と全く同じです。通常、これはテーブル名を含める唯一のフィールドです。

プレーンID名は嫌いです。私は常にinvoice_idまたはその変形を使用することを強くお勧めします。私は必要なときに、どのテーブルがidの信頼できるテーブルであるかを常に知っていますが、これは私を混乱させます

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID 

すべての中で最悪なのは、あなたが言及するミックスであり、完全に混乱しています。最も使用されているIDの1つを除いて、ほとんどの場合foo_idであるデータベースを使用する必要がありました。それは完全に地獄でした。

私はDomainNameを好む|| 「ID」。（つまり、ドメイン名+ ID）

DomainNameは多くの場合TableNameと同じですが、常にではありません。

ID自体の問題は、それが上方向にスケーリングしないことです。約200のテーブルがあり、それぞれにIDという名前の最初の列があると、データはすべて同じに見え始めます。IDを常にテーブル名で修飾する場合、少しは役立ちますが、それほど役立ちません。

DomainName＆IDを使用して、主キーだけでなく外部キーにも名前を付けることができます。外部キーがそれらが参照する列にちなんで名前が付けられている場合、それはニーモニックに役立ちます。参照整合性制約によって参照が確立されるため、正式には、外部キーの名前をそれが参照するキーに関連付ける必要はありません。しかし、クエリや更新の読み取りに関しては非常に便利です。

時折、DomainName || 同じ名前の同じテーブルに2つの列があるため、 'ID'は使用できません。例：Employees.EmployeeIDおよびEmployees.SupervisorID。そのような場合は、RoleNameを使用します|| 例のように、「ID」。

最後に重要なことですが、可能な場合は合成キーではなく自然キーを使用します。自然キーが利用できない、または信頼できない状況もありますが、自然キーが適切な選択である状況はたくさんあります。そのような場合、私は自然キーが自然に持つ名前を引き継ぐようにします。この名前には、「ID」という文字が含まれていないことがよくあります。例：OrderNoここで、Noは「番号」の省略形です。

各テーブルについて、ツリーレターの短縮形を選択します（例：従業員=>従業員）

これにより、数値の自動番号主キーがnkEmpになります。

これは短く、データベース全体で一意であり、そのプロパティを一目で正確に把握できます。

私はSQLと使用するすべての言語（主にC＃、Javascript、VB6）で同じ名前を使用しています。

テーブルと列に名前を付ける十分に考えられたシステムについては、Interaktサイトの命名規則を参照してください。このメソッドは、各テーブル（_prd製品テーブルまたは_ctgカテゴリテーブル）のサフィックスを使用し、それを特定のテーブルの各列に追加します。したがって、productsテーブルのID列id_prdはデータベース内で一意になるため、データベース内で一意になります。

それらは、外部キーの理解を助けるためにさらに一歩進みます：カテゴリーテーブルを参照する製品テーブルの外部キーは、idctg_prdそれが属するテーブル（_prd接尾辞）とそれが参照するテーブル（カテゴリー）を明確にするためのものです。。

利点は、さまざまなテーブルのID列にあいまいさがなく、列名によってクエリが参照している列が一目でわかることです。

主キー/外部キーの命名規則も参照してください

次の命名規則を使用できます。それには欠点がありますが、特定の問題を解決します。

1. テーブル名には短い（3〜4文字の）ニックネームを使用します。つまりinv、Invoice-、InvoiceLines-invl
2. これらのニックネームを使用して、テーブルの列に名前を付けますinv_id。invl_id
3. 参照列についてはinvl_inv_id、名前に使用します。

このように言うことができます

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id