Соглашения об именах столбцов и рекомендации

Я хотел бы получить экспертное мнение о передовой практике, когда дело доходит до именования столбцов .

Фон в том, что согласно Википедии , следующий синтаксис,

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.

Будем также благодарны за любые ссылки на стили дизайна или лучшие практические руководства по оформлению таблиц!

Об этом уже спрашивали на SO.

Там, где у вас есть общие и очень неоднозначные имена, тогда префикс с именем таблицы. То есть, все, что вы склонны иметь псевдоним почти в каждом запросе.

Так что для таблицы сотрудников я бы

EmployeeID
EmployeeName
Comment
Salary
StartDate
EndDate
InsertedDateTime
...

И Википедия на самом деле говорит:

Однако конструкция USING - это больше, чем просто синтаксический сахар, поскольку набор результатов отличается от набора результатов версии с явным предикатом. В частности, любые столбцы, упомянутые в списке USING, будут отображаться только один раз с неквалифицированным именем, а не один раз для каждой таблицы в объединении.

Это на один столбец меньше. Вы никогда не будете использовать в SELECT *любом случае, так что вопрос спорный ...

Следующая книга рассказывает об использовании 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

Это особая проблема, когда вы создаете сложную отчетность и вам требуется более одного идентификатора, так как тогда вам нужен псевдоним. Использование идентификатора имени таблицы также облегчает определение правильного FK для присоединения (поскольку они имеют одинаковое имя) и снижает вероятность ошибок при присоединении к неправильному объекту.

Тем не менее, многие базы данных не поддерживают синтаксис USING, поэтому проблема, с которой вы столкнулись, не является проблемой для этих баз данных. Но многие базы данных не поддерживают использование естественного соединения, которое я бы не рекомендовал использовать ни при каких обстоятельствах, так как они могут измениться. если структура таблицы изменится. Итак, предположим, что вы добавили поле с именемifieddate в обе таблицы, вы не захотите присоединяться к нему, но естественное объединение сделает это.

Лучше явно указывать имя таблицы и столбца, например Employees.EmployeeID, с выражениями, в которых существует объединение.