Ім'я стовпця, що називає конвенції та кращі практики

19

Я хотів би отримати деяку експертну думку щодо найкращих практик щодо імен стовпців .

Фоном є те, що згідно Вікіпедії , наступний синтаксис,

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

є більш ефективним, ніж

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

Однак JOIN ... USINGсинтаксис, який працює лише у всіх стовпцях первинного ключа, має унікальні назви у всьому світі . Таким чином, мені цікаво, чи вважається це правильною справою.

Особисто я завжди використовував для створення таблиць із стовпчиком ПК та стовпцем із idзовнішнім ключем othertable_id. Але таким чином це не представляється можливим використовувати USINGі NATURAL JOIN.

Будемо також вдячні будь-які посилання на стилі дизайну чи посібники з найкращих практик для дизайну столів!

database-design join naming-convention

— Керрек СБ
джерело

3

Вікіпедія помилкова. Перша версія ні в якому разі не є більш ефективною, ніж друга. Під капотом база даних створить абсолютні ідентичні запити

— a_horse_with_no_name

13

Про це запитували раніше в SO.

Там, де у вас є загальні і дуже неоднозначні назви, тоді приставка з назвою таблиці. Тобто, все, що ви зобов'язані мати, має псевдонім майже в кожному запиті.

Тож за столом працівника я мав би

EmployeeID
EmployeeName
Comment
Salary
StartDate
EndDate
InsertedDateTime
...

А Вікіпедія насправді говорить:

Однак конструкція USING - це не просто синтаксичний цукор, оскільки набір результатів відрізняється від набору результатів версії явним предикатом. Зокрема, будь-які стовпці, згадані у списку USING, з’являться лише один раз з некваліфікованим іменем, а не один раз для кожної таблиці в об’єднанні.

Це одна колонка менше. Ви ніколи не будете користуватися, SELECT *тому справа суперечлива ...

— гбн
джерело

Я не думав шукати ТАК - нерозумно мене. Чи є у вас посилання на будь-які особливо хороші запитання? У будь-якому випадку, дякую, я відтепер буду дотримуватися "унікального ідентифікатора"!

— Керрек СБ

@Kerrk SB: насправді я цього не зробив. Я схильний їх ігнорувати, тому що кожен отримує відповіді або закриває швидко :-) Вибачте

— gbn

Я хотів би побачити ці подібні запитання на ТАК, якщо хтось може перекопати посилання. Я приїхав сюди, тому що там не міг знайти питання, і був впевнений, що його вже запитують. Я одразу ж знайшов це питання.

— Ніколас Шенкс

Це було на програмістах.SE. Приємна велика боротьба з вами ... programmers.stackexchange.com/questions/114728/…

— gbn

6

У наступній книзі йдеться про використання 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, що робить проблему, яку ви створили, не є проблемою для цих баз даних. Ніяка кількість баз даних не підтримує природне з'єднання, яке я не рекомендував би використовувати в будь-якому навіть тому, що вони можуть приєднатися. якщо змінюються структури таблиць. Отже, припустимо, що ви додаєте поле, яке називається модифікований, до обох таблиць, ви б не хотіли приєднуватися до цього, але природне об'єднання зробило б це.

— HLGEM
джерело

4

Краще чітко вказати ім’я таблиці та ім’я стовпців, як Employees.E EmployeeEID з виразами, де існує з'єднання

— Еральпер
джерело