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

19

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

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

より効率的です

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

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

個人的に、私はいつもPK column id、および外部キーcolumnを持つテーブルを作成するために使用していましたothertable_id。しかし、その方法ではUSINGまたはを使用することはできませんNATURAL JOIN。

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

database-design join naming-convention

— ケレックSB
ソース

3

ウィキペディアは間違っています。最初のバージョンは、2番目のバージョンよりも効率的ではありません。ボンネットの下にデータベースが同じクエリABSOLUT作成します

— a_horse_with_no_name

13

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

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

だから私は持っているだろう従業員テーブル

EmployeeID
EmployeeName
Comment
Salary
StartDate
EndDate
InsertedDateTime
...

ウィキペディアは実際にこう言っています：

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

これは1列少ないです。SELECT *とにかく使用しないので、ポイントは重要ではありません...

— GBN
ソース

私はSOを検索することを考えていませんでした-愚かな私。SOに関する特に良い質問へのリンクはありますか？とにかく、おかげで、私は今後「固有のID」命名に固執しなければならない！

— ケレックSB

@Kerrk SB：実際、そうではありません。それぞれが答えたかすぐに:-)申し訳ありませんが閉じますので、私はそれらを無視する傾向がある

— GBN

誰かがリンクを掘ることができるなら、私はSOでそれらの同様の質問を見たいです。質問が見つからなかったので、ここに来ました。すでに質問されていたと確信していました。私はすぐにこの質問を見つけました。

— ニコラスシャンクス

それは、programmers.SEにありました。あなたのための素敵な大きなバンの戦い... Programmers.stackexchange.com/questions/114728/…–

— gbn

6

次の本は、SQLのアンチパターンとしてIDを使用することについて語っていますが、著者にそのことを承諾します。 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が必要な場合に特に問題になります。テーブル名IDを使用すると、（同じ名前を持っているため）結合する正しいFKを識別しやすくなり、間違ったものへの結合によるエラーが発生しにくくなります。

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

— HLGEM
ソース

4

結合が存在する式を使用して、Employees.EmployeeIDなどのテーブル名と列名を明示的に指定することをお勧めします

— エラルパー
ソース