web-dev-qa-db-ja.com

2つの列が同じテーブルを参照する場合の外部キーの命名基準はありますか？

私はいつもFK_CurrentTableName_ReferencedTableNameという名前を使用しています。 CreatedByIdとModifiedByIdが両方とも同じ（ユーザー）テーブルを指しているテーブルを取得したので、この命名規則は機能しません。

実際にすべての参照制約をFK_CurrentTableName_CurrentColumnNameに変更する方が良いですか？または、競合がない限り同じままにして、FK_CurrentTableName_CurrentColumnName_ReferencedTableNameまたはFK_CurrentTableName_ReferencedTableName_CurrentColumnNameを実行する必要がありますか？

私は相反する意見を検索して読みました。 SQL Serverの場合、標準はありますか？

sql-serverdatabase-designforeign-key
5
jnm2

いいえ、これに関する標準の命名規則はありません。また、他のシナリオについても同様です。命名規則は純粋に主観的です：your規則は意味があり、使用するyour標準は一貫していて、どちらもmuchは、選択する標準よりも重要です。

つまり、この場合、このオプションを選択します。

FK_CurrentTable_Created_Users
FK_CurrentTable_Modified_Users

これにより、実際の定義を取得する困難な労力をかけずに、この外部キーについて何かを推測したい場合に必要なすべての情報が提供されます。これだけを使用する場合：

FK_CurrentTable_Created

次に、他のテーブルに関する情報を取得しません。この特定のケースでは、推論するのは簡単ですが、常にそうであるとは限りません。これを使用する場合：

FK_CurrentTable_Users_Created

順序が間違っているように感じます。 「この表は、列xでその表を参照しています。」 「このテーブルの列xはそのテーブルを参照している」と言う方がはるかに直感的です。両側で完全な参照が必要になることもあります（もちろん、usersテーブルには複数の候補キーがある場合がありますが、FKがサロゲートではなく候補/自然キーを指すことはめったにありません）。

FK_CurrentTable_Created_Users_UserID

そしてそこに問題があります。この決定は、定義によって、意見に基づいて行われる必要があるため、矛盾する意見を見つけ続けることになります。誰もが同意するわけではありません。

7
Aaron Bertrand

いくつかのランダムな考え、おそらくそこには多くの標準がありますが、世界的に標準として受け入れられているものはありません。私はアーロンに同意します。あなたが決めることは何でも、プロジェクト全体でそれを続けることに同意します。

命名規則は多くの事柄に依存し、DBMSもその1つです。制約の名前は、テーブル内で一意になる場合もあれば、データベース内で一意になる場合もあります。おそらく、一部の製品では、スキーマ内で一意に扱われます。

DB2 LUW（私が最もよく使用するDBMS）の場合、名前はテーブル内で一意です（同じ名前をテーブル間で再利用できます）。違反している制約の名前は、エラーメッセージで切り捨てられることが多く、どの表が関係するかは多くの場合明白です。複数の列を含む外部キーを持つこともよくあります。そのため、次の規則を使用します。

  • PK_ [TABLE]-主キー制約
  • AKn_ [TABLE]-代替キー、一意制約
  • Cn_ [TABLE]-チェック制約
  • FKn_ [PARENT_TABLE]-外部キー制約

トピックから少し外れていますが、トリガーの場合：

  • IRBn_ [TABLE]-挿入、行、前
  • DRAn_ [TABLE]-削除、行、後
  • USAn_ [TABLE]-更新、ステートメント、後

そして4番目。

私はSQL Serverについて十分な知識を持っているわけではありませんが、さまざまな考慮事項についていくつかのアイデアが得られることを願っています。

4
Lennart