sql - データベーステーブルのID列の命名

Question

データベーステーブルのID列の命名について、人々の意見を聞いていました。

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

私が現在働いているところでは、彼らはすべてのID列をIDと呼んでいます。

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

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

ここで、いくつかの問題が発生します
。1.選択した列のエイリアスを作成する必要があります
。2。ID = InvoiceIDが私の頭の中に収まりません。3。
テーブルのエイリアスを作成せず、InvoiceIDを参照した場合、どのテーブルかは明らかです。オンですか？

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

Answer 1

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

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

Answer 2

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

例えば

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

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

Answer 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

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

Answer 4

InvoiceIDではなくを使用しますID。これにより、クエリが読みやすくなります。ID単独で見ると、特にテーブルのエイリアスをi.

Answer 5

私は、テーブルのPKは単にIdであり、外部キーはOtherTable + Idをリストする必要があるという、Kevenと他の数人の人々に同意します。

しかし、最近この議論に重きを置いた理由を1つ付け加えたいと思います。

私の現在の位置では、POCO生成を使用するエンティティフレームワークを採用しています。Idの標準の命名規則を使用すると、PKは、共通の列名のセットを共有するテーブルの検証などを使用して、基本pocoクラスを継承できます。これらの各テーブルのPKとしてTablename+Idを使用すると、これらの基本クラスを使用する機能が破壊されます。

考えのためのほんの少しの食べ物。

Answer 6

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

i.ID , il.ID を Invoices i から選択
i.ID = il.InvoiceID で InvoiceLines il を結合

なぜ私はこれを行うことができないのですか？

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

私の意見では、これは非常に読みやすくシンプルです。変数に i および il という名前を付けることは、一般的には適切な選択ではありません。

Answer 7

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

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

Answer 8

「ID」のみを使用する場所（コアテーブルで、外部キーのTableNameIDによって参照される）で作業を開始したばかりで、それが直接原因である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" は現在コア テーブルの代わりに一時テーブルを使用しても、エラーは発生しません。結果が間違っているだけです。

不要なエラーを生成することが目標である場合 (作業が不十分な人もいるかもしれません)、この種の命名規則は優れています。それ以外の場合は、一貫した名前付けが有効です。

Answer 9

個人的には (上で述べたように) PKにはTable.IDを、FKにはTableIDを好みます。(私を撃たないでください) Microsoft Access もこれを推奨しています。

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

クエリ デザイナーでさえ、Microsoft SQL Server でこれを行います (作成するクエリごとに、列 ID のすべてのテーブルで新しく作成された不要なリレーションシップをすべて剥ぎ取ることになります)。

したがって、私の内部 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
  

[アップデート]

また、このスレッドには、「関係の種類」または役割が原因で列が重複しているという有効な投稿がいくつかあります。たとえば、 Store にEmployeeIDがある場合、しゃがんでいることがわかります。だから私は時々 Store.EmployeeID_Managerのようなことをします。確かに少し大きくなりますが、少なくともテーブル ManagerIDやEmployeeIDがそこで何をしているのかを見つけようとして夢中になることはありません。クエリが WHERE の場合、次のように単純化します: SELECT EmployeeID_Manager as ManagerID FROM Store

Answer 10

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

Answer 11

これを正式なデータ ディクショナリの観点から考えると、私はデータ要素に名前を付けますinvoice_ID。一般に、データ要素名はデータ ディクショナリ内で一意であり、理想的には全体を通して同じ名前を持ちますemployee_ID。supervisor_employee_IDそしてsubordinate_employee_IDそれぞれ。

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

DBMS の場合、テーブルはエンティティのコレクションとして認識されます (cofig テーブル、定数テーブルなど、1 つの行のみを含むものを除く)。たとえば、 myemployee_IDがキーであるテーブルはPersonnel. そのため、すぐにTableNameID慣習はうまくいきません。

私はTableName.ID=PK TableNameID=FK大規模なデータモデルで使用されているスタイルを見たことがありますが、少し混乱していると言わざるを得ません.識別子の名前は全体を通して同じである方がずっと好きです.つまり、どのテーブルにたまたま現れたかに基づいて名前を変更しません.注意すべきことは前述のスタイルは、外部キーの自然キーと複合キーを避けながら、すべてIDENTITYのテーブルに（自動インクリメント）列を追加するショップで使用されているようです。これらのショップは、正式なデータ ディクショナリを持っておらず、データ モデルから構築することもありません。繰り返しますが、これは単にスタイルの問題であり、私が個人的に同意するものではありません. 結局、それは私のためではありません。

そうは言っても、テーブルの名前がそうするためのコンテキストを提供する場合、列名から修飾子を削除する場合があることがわかります。たとえば、名前付きの要素がテーブル内でemployee_last_name単純last_nameになる場合がありPersonnelます。ここでの論理的根拠は、ドメインが「人々の姓」であり、別のテーブルの外部キーとして使用されるよりも、他のテーブルの列でUNION編集される可能性が高いということですが、もう一度... 私は気が変わるかもしれません.わからないこともあります。つまり、データ モデリングは芸術であり、科学でもあります。last_name

Answer 12

FWIW、私たちの新しい標準（これは、新しいプロジェクトごとに「進化する」という意味で変更されます）は次のとおりです。

• 小文字のデータベースフィールド名
• 大文字のテーブル名
• アンダースコアを使用してフィールド名の単語を区切ります-コードでこれらをパスカルケースに変換します。
• 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'）

ただし、他の人が言っているように、一貫性があり、意味を不必要に曖昧にしない限り、ほぼすべてのスキームが機能します。

Answer 13

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

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

乾杯、ベン

Answer 14

私の投票は、テーブル 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

確かに、他の例よりも長いです。でも笑顔。これは後世のためのものであり、いつか貧しいジュニア コーダーがあなたの傑作を変更しなければならなくなるでしょう。この例にはあいまいさがなく、追加のテーブルがクエリに追加されると、その冗長性に感謝するでしょう。

Answer 15

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

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

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

Answer 16

「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 は、より冗長にならなくても十分に冗長です。

Answer 17

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

Answer 18

私は平凡な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 であるデータベースで作業する必要がありました。それは完全な地獄でした。

Answer 19

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

私にとって、これは、読みやすいと思う結合では特に理にかなっています。

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

Answer 20

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

外部キーの理解を助けるために、さらに一歩進んでいます。カテゴリ テーブルを参照する製品テーブルの外部キーは、idctg_prdどのテーブルに属しているか (_prdサフィックス)、どのテーブルを参照しているか (カテゴリ)が明確になるようにします。 .

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

Answer 21

|| DomainName の方が好みです || 「ID」。(つまり、ドメイン名 + ID)

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

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

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

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

最後になりましたが、可能な場合は合成キーではなく自然キーを使用します。自然キーが利用できない、または信頼できない状況もありますが、自然キーが正しい選択である状況はたくさんあります。そのような場合、自然キーに自然に付けられる名前を付けさせます。この名前には、多くの場合、「ID」という文字さえ含まれていません。例: OrderNo No は「Number」の略語です。

Answer 22

テーブルごとにツリー文字の略記を選択します (例: Employees => Emp)

そうすれば、数値自動付番の主キーがnkEmpになります。

短く、データベース全体で一意であり、一目でそのプロパティが正確にわかります。

SQL と使用するすべての言語 (主に C#、Javascript、VB6) で同じ名前を使用しています。

Answer 23

これについてはすでに多くの回答がありますが、上記で見たことのない 2 つの主要な点を追加したいと思います。

• サポートに来てくださるお客様。

多くの場合、顧客、ユーザー、または別の部門の開発者でさえも問題にぶつかり、操作に問題があると連絡してきました。問題が発生しているレコードを尋ねます。現在、顧客名、注文数、目的地などのグリッドなど、画面に表示されるデータは、多くのテーブルの集合体です。彼らは、ID 83 に問題があると言っています。「id」と呼ばれるだけでは、それがどの ID で、どのテーブルであるかを知る方法はありません。

つまり、データの行は、それがどのテーブルからのものかを示すものではありません。たまたまデータベースのスキーマをよく知っていない限り (複雑なシステムや、引き継ぐように言われた未開発のシステムではめったにありません)、より多くのデータがあっても id=83 が何を意味するのかわかりません。名前、住所など (同じテーブルにあるとは限りません!)。

この ID はグリッドから取得されたものであるか、API のエラーから取得されたものである可能性や、エラー メッセージを画面またはログ ファイルにダンプする不適切なクエリから取得されたものである可能性があります。

多くの場合、開発者は「ID」を列にダンプするだけでそれを忘れます。多くの場合、DB には Invoice、InvoiceGrouping、InvoicePlan などの類似のテーブルが多数あり、ID はそれらのいずれかである可能性があります。イライラして、コードを調べてそれがどれであるかを確認すると、モデルでも Id と呼ばれていることがわかります。そのため、ページのモデルがどのように構築されたかを掘り下げる必要があります。Id が何であるかを理解するために、これを何回実行しなければならなかったか数え切れません。それは多い。ヘッダーとして「Id」を返すだけの SPROC も掘り出す必要がある場合があります。悪夢。

• 何が問題だったのかが明確になると、ログ ファイルがより簡単になります

多くの場合、SQL は非常にくだらないエラー メッセージを表示することがあります。「ID 83 のアイテムを挿入できませんでした。列が切り捨てられます」など、デバッグが非常に困難です。多くの場合、エラー メッセージはあまり役に立ちませんが、通常、破損したものは、主キーの名前と値をダンプするだけで、どのレコードが破損したかをあいまいに伝えようとします。それが「ID」である場合、それはまったく役に立ちません。

これは、他の回答で言及されていないと感じた2つのことです。

また、多くのコメントが「X の方法でプログラムする場合、これは問題にならない」というものだと思います。上記のポイント (およびこの質問に関するその他のポイント) は、特に人々のプログラミング方法と、彼らには、完璧なロギングとエラー処理をプログラミングしたり、SQL やコードをすばやく書くという根深い習慣を変えたりするための時間、エネルギー、予算、先見の明がありません。

Answer 24

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

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

このようにあなたは言うことができます

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id