web-dev-qa-db-ja.com

列名の命名規則とベストプラクティス

列の命名に関しては、ベストプラクティスに関する専門家の意見をお願いします。

背景は Wikipediaによると 、次の構文、

SELECT ... FROM Employees JOIN Timesheets USING (EmployeeID);

よりも効率的です

SELECT ... FROM Employees JOIN Timesheets ON (Employees.EmployeeID = Timesheets.EmployeeID);

ただし、JOIN ... USING構文は、すべての主キー列がグローバルに一意の名前でのみ機能します。したがって、これは正しいことだと考えられているのでしょうか。

個人的には、常にPK列idと外部キー列othertable_idを使用してテーブルを作成していました。ただし、この方法ではUSINGまたはNATURAL JOINを使用できません。

デザインスタイルやテーブルデザインのベストプラクティスガイドへのリンクも歓迎します。

database-designjoinnaming-convention
19
Kerrek SB

これはSOで以前に尋ねられました。

一般的で非常にあいまいな名前がある場合は、テーブル名を前に付けます。つまり、ほとんどすべてのクエリでエイリアスする必要があるすべてのものです。

だから従業員テーブルの場合、

EmployeeID
EmployeeName
Comment
Salary
StartDate
EndDate
InsertedDateTime
...

そしてウィキペディアは実際に言う：

ただし、結果セットは、明示的な述語を持つバージョンの結果セットとは異なるため、USING構文は単なる構文上の糖衣ではありません。具体的には、USINGリストで言及されている列は、結合の各テーブルに対して1回ではなく、非修飾名で1回だけ表示されます。

それは1列少ないです。とにかくSELECT *を使用することはないので、要点は...

13
gbn

次の本では、IDをSQLのアンチパターンとして使用する方法について説明しており、筆者と同じだと思います。 http://www.Amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=sr_1_1?s=books&ie=UTF8&qid=1330025134&sr=1-1

これは、複雑なレポートを作成していて、エイリアスを作成する必要があるために複数のIDが必要な場合に特に問題になります。 tablename IDを使用すると、正しいFKを識別しやすくなり（同じ名前であるため）、間違ったものへの結合によるエラーが発生する可能性が低くなります。

そうは言っても、多くのデータベースはUSING構文をサポートしていないため、あなたが提起した問題はこれらのデータベースの問題ではありません。テーブル構造が変更された場合。したがって、modifieddateというフィールドを両方のテーブルに追加するとします。そのフィールドでは結合したくないのですが、自然結合ではそうなります。

6
HLGEM

結合が存在する式では、Employees.EmployeeIDのようにテーブル名と列名を明示的に指定することをお勧めします

4
Eralper