Konwencje nazewnictwa nazw kolumn i najlepsze praktyki

Chciałbym uzyskać ekspertyzę dotyczącą najlepszych praktyk w zakresie nazewnictwa kolumn .

Tło jest takie, że według Wikipedii następująca składnia:

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

jest bardziej wydajny niż

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

Jednak JOIN ... USINGskładnia działa tylko dla wszystkich kolumn klucza podstawowego o globalnie unikatowych nazwach . Zastanawiam się więc, czy uważa się to za słuszne.

Osobiście zawsze tworzyłem tabele z kolumną PK idi kolumną z kluczem obcym othertable_id. Ale w ten sposób nie można użyć USINGlub NATURAL JOIN.

Doceniamy również wszelkie linki do stylów projektowania lub przewodników najlepszych praktyk w zakresie projektowania stołów!

Zostało to już wcześniej zadane na SO.

Tam, gdzie masz pospolite i bardzo niejednoznaczne nazwy, poprzedz je nazwą tabeli. Oznacza to, że wszystko, co możesz mieć, musi mieć alias w prawie każdym zapytaniu.

Tak więc na stole pracowniczym miałbym

EmployeeID
EmployeeName
Comment
Salary
StartDate
EndDate
InsertedDateTime
...

A Wikipedia faktycznie mówi:

Konstrukt USING jest jednak czymś więcej niż zwykłym cukrem syntaktycznym, ponieważ zestaw wyników różni się od zestawu wyników wersji z wyraźnym predykatem. W szczególności wszelkie kolumny wymienione na liście USING pojawią się tylko raz, z niekwalifikowaną nazwą, a nie raz dla każdej tabeli w złączeniu.

To o jedną kolumnę mniej. I tak nigdy byś nie użył, SELECT *więc chodzi o dyskusję ...

Poniższa książka mówi o używaniu ID jako antipatternu SQL i zgadzam się z tym, że tak jest. http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=sr_1_1?s=books&ie=UTF8&qid=1330025134&sr=1-1

Jest to szczególny problem, gdy wykonujesz złożone raporty i potrzebujesz więcej niż jednego identyfikatora, ponieważ musisz wtedy dokonać aliasu. Użycie identyfikatora tablename ułatwia także identyfikację właściwego FK, do którego należy dołączyć (ponieważ mają one tę samą nazwę) i sprawia, że ​​błędy w łączeniu z niewłaściwą rzeczą są mniej prawdopodobne.

To powiedziawszy, wiele baz danych nie obsługuje składni USING, co sprawia, że ​​problem, który poruszyłeś, nie stanowi problemu dla tych baz danych. Ani nie obsługuje wielu baz danych przy użyciu naturalnego łączenia, którego nie poleciłbym w żadnym przypadku, gdy łączą się, mogłyby się zmienić jeśli zmieni się struktura tabeli. Załóżmy więc, że dodasz pole o nazwie zmodyfikowanej do obu tabel, nie chciałbyś się do tego przyłączać, ale zrobiłoby to naturalne sprzężenie.

Lepiej jest jawnie podać nazwę tabeli i nazwę kolumny, np. Employees.EmployeeID z wyrażeniami, w których istnieje połączenie