主キー/外部キーの命名規則[終了]

私たちの開発グループでは、主キーと外部キーの命名規則に関して激しい議論があります。私たちのグループには、基本的に2つの考え方があります。

1：

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

または

2：

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

私は、どの列でもテーブルの名前を複製しないことを好みます（したがって、上記のオプション1を好みます）。概念的には、プロパティ名にオブジェクトの名前を使用しない他の言語で推奨されている多くの慣習と一致しています。私は、外部キーに名前を付けるとEmployeeID（またはそれEmployee_IDよりも良いかもしれません）、それが表のID列であることを読者に伝えると思いますEmployee。

列名がデータベース全体で同じになるように、テーブル名を前に付けた主キーに名前を付けるオプション2を好む人もいます。その点はわかりましたが、主キーと外部キーを視覚的に区別することはできなくなりました。

また、私はそれはあなたがエンティティとそのエンティティのプロパティまたは属性として列としてテーブルを考えるならば、あなたはのID属性と考えるので、列名にテーブル名を持つように冗長だと思うEmployee、ありませんEmployeeID従業員の属性。私は同僚に何を言っているのPersonAgeか尋ねませんPersonGender。私は彼に彼の年齢は何であるか尋ねます。

だから私が言ったように、それは激しい議論であり、私たちはそれについて何度も何度も繰り返します。私はいくつかの新しい視点を得ることに興味があります。

それは本当に重要ではありません。選択肢1と選択肢2に実際の違いがあるシステムに出くわしたことはありません。

ジェフ・アトウッドはこのトピックについてしばらく前に素晴らしい記事を書いてくれました。基本的に人々は、彼らが間違っていると証明できないこれらのトピックについて最も激しく議論し、議論します。または別の角度から見ると、フィリバスタースタイルの持久力に基づく最後の常人の議論によってのみ獲得できるトピック。

1つを選択して、実際にコードに影響を与える問題に集中するように伝えます。

編集：楽しみたい場合は、その方法が再帰的なテーブル参照に優れている理由を詳細に指定してもらいます。

2つの列が両方のテーブルで同じ名前である場合（慣例＃2）、SQLのUSING構文を使用して、入力とボイラープレートノイズを節約できます。

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

規約＃2を支持するもう1つの議論は、これがリレーショナルモデルの設計方法だということです。

各列の重要性は、対応するドメインの名前でラベル付けすることによって部分的に伝えられます。

アプリケーションの組み立て方次第だと思います。ORMを使用するか、オブジェクトを表すためにテーブルを設計する場合、オプション1が適しています。

データベースを独自のレイヤーとしてコーディングするのが好きです。私はすべてを制御し、アプリはストアドプロシージャを呼び出すだけです。特に結合されたテーブルが多く、返された列が多い場合は、結果セットに完全な列名を付けると便利です。このタイプのアプリケーションでは、オプション2が好きです。結合で列名が一致するのを確認したいのです。私は古いシステムで作業しましたが、それらが一致せず、悪夢でした。

どちらの規約もすべてのケースで機能するわけではないので、なぜ1つしかないのでしょうか。常識を使う...

たとえば、自己参照テーブルの場合、同じテーブルのPKを自己参照する複数のFK列がある場合、2つのFK列に同じ名前を付けることはできないため、両方の「標準」に違反する必要があります...例えば、EmployeeId PK、SupervisorId FK、MentorId Fk、PartnerId FKなどのEmployeeTable ...

それらの間で選択することはほとんどないことに同意します。どちらの標準についても私にとってはるかに重要なことは、「標準」の部分です。

人々が「自分でやること」を始めるなら、彼らは彼らの地獄に縛られているはずです。私見では ：）

次のことを検討しましたか？

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

私が使用する規則は、Aにかなり似ていますが、複数形（つまり、「従業員」）でテーブルに名前を付け、テーブル名と列名の間にアンダースコアを使用している点が異なります。この列の利点は、列へのアクセス方法に応じて、「employees _ id」または「employees.id」のいずれかになることです。列の取得元のテーブルを指定する必要がある場合、 "employees.employees _ id"は間違いなく冗長です。

データベースクエリだけでなく、アプリケーションコードも見てみると、いくつかのことがはっきりとわかります。

1. テーブル定義は通常、1つのオブジェクトを記述するクラスに直接マップされるため、それらは単数である必要があります。オブジェクトのコレクションを説明するために、通常、単数形の名前に「配列」、「リスト」、または「コレクション」を追加します。複数形を使用するよりも、それがコレクションであることだけでなく、どのようなコレクションであるかを明確に示すためですそうです。そのビューでは、テーブル名はコレクションの名前ではなく、それがコレクションであるオブジェクトのタイプの名前として表示されます。アプリケーションコードを記述しないDBAは、この点を見落とす可能性があります。

2. 私が扱うデータでは、非キー識別の目的で「ID」を使用することがよくあります。キー "ID"と非キー "ID"の混同を避けるために、主キーの名前には、テーブル名またはその省略形を前に付けた "Key"（つまり、そうですね）を使用します。テーブル名。この接頭辞（および私はこれを主キーに対してのみ予約します）はキー名を一意にします。これは、データベースの列名と同じ変数名を使用し、ほとんどのクラスには、親キー。これは、「Key」だけのように、予約済みキーワードではないことを確認するためにも必要です。キー変数名の一貫性を維持し、自然結合を行うプログラムを提供するには、外部キーは、それらが主キーである表で使用されているものと同じ名前です。自然結合を使用してこの方法ではるかにうまく機能するプログラムに一度以上遭遇しました。この最後の点で、私が使用した自己参照テーブルの問題を認めます。この場合、外部キーの命名規則に例外を設けます。たとえば、ManagerキーをEmployeeテーブルの外部キーとして使用して、そのテーブルの別のレコードをポイントします。

私はコンベンション＃2が好きです。このトピックを調査し、自分の質問を投稿する前にこの質問を見つけると、次の問題に遭遇しました。

多数の列を持つテーブルから*を選択し、それを同様に多数の列を持つ2番目のテーブルに結合しています。どちらのテーブルにも主キーとして「id」列があります。つまり、結果でこれらの2つの値を一意にするために、（私の知る限り）すべての列を具体的に選択する必要があります。

SELECT table1.id AS parent_id, table2.id AS child_id

規則＃2を使用すると、同じ名前の列が結果に含まれることになりますが、必要なID（親または子）を指定できるようになり、Steven Huwigが示唆したように、USINGステートメントによってさらに単純化されます。

私は常に1つのテーブルのPKとしてuserIdを使用し、別のテーブルのuserIdをFKとして使用してきました。userIdPKとuserIdFKを名前として使用して、お互いを識別することを真剣に考えています。テーブルを見るときにPKとFKをすばやく特定するのに役立ちます。また、PHP / SQLを使用してデータにアクセスすると、コードがわかりやすくなり、理解しやすくなります。特に誰かが私のコードを見るとき。

規約＃2を使用します。現在、レガシーデータモデルで作業していますが、指定されたテーブルの意味がわかりません。冗長であることの害はどこにありますか？

外部キーに名前を付けるのはどうですか

role_id

ここで、roleは、参照されるエンティティが手元のテーブルに関連する役割です。これにより、同じテーブルへの再帰参照と複数のfkの問題が解決されます。

多くの場合、参照されるテーブル名と同じになります。この場合、それは提案の1つとまったく同じになります。

いずれにせよ、長い議論は悪い考えです

「 "employee INNER JOIN order ON order.employee_id = employee.id"のどこに追加の資格が必要ですか？」

私が話した資格はすでにそこにあるので、追加の資格は必要ありません。

「ビジネスユーザーが注文IDまたは従業員IDを参照する理由は、コンテキストを提供するためですが、データベースを参照しているため、データベースレベルではすでにコンテキストがあります。」

列が 'ID'という名前の場合、私が言ったようにID列へのこの参照を正確に修飾しない限り、「テーブルへの[sic]の参照」はどのように行われますか？