Конвенція про іменування первинних ключів / іноземних [закрита]

У нашій групі розробників у нас бурхлива дискусія стосовно конвенції про іменування первинних та іноземних ключів. В нашій групі є дві школи думки:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

або

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

Я вважаю за краще не дублювати назву таблиці в жодному з стовпців (тому я віддаю перевагу варіант 1 вище). Концептуально це відповідає багатьом рекомендованим практикам на інших мовах, де ви не використовуєте ім'я об'єкта у його назвах властивостей. Я думаю, що називання зовнішнього ключа EmployeeID(або, Employee_IDможливо, краще) говорить читачеві, що це IDстовпець Employeeтаблиці.

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

Крім того, я думаю, що зайвим є ім’я таблиці у назві стовпців, тому що якщо ви вважаєте таблицю сутністю, а стовпець - властивістю чи атрибутом цього об'єкта, ви вважаєте це атрибутом ID Employee, а не EmployeeIDатрибут працівника. Я не ходжу запитати мій товариш по службі , що його PersonAgeабо PersonGenderє. Я запитую його, який його вік.

Так, як я вже сказав, це бурхлива дискусія, і ми продовжуємо цю справу. Мені цікаво отримати нові перспективи.

Це насправді не має значення. Я ніколи не стикався з системою, де існує реальна різниця між вибором 1 і вибором 2.

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

Виберіть його та скажіть їм, щоб зосередитися на проблемах, які насправді впливають на ваш код.

EDIT: Якщо ви хочете розважитися, попросіть їх докладно вказати, чому їх метод перевершує рекурсивні посилання на таблицю.

Якщо обидва стовпці мають однакове ім’я в обох таблицях (конвенція №2), ви можете використовувати синтаксис USING у SQL, щоб зберегти деякий набір тексту та деякий шум котла:

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

Ще один аргумент на користь конвенції №2 полягає в тому, що саме так була розроблена реляційна модель .

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

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

Мені подобається кодувати базу даних як власний рівень. Я контролюю все, і додаток просто викликає збережені процедури. Приємно мати набори результатів із повними іменами стовпців, особливо коли багато об’єднаних таблиць і повернуто багато стовпців. З цим стилем застосування мені подобається варіант 2. Мені дуже подобається, щоб назви стовпців збігалися при приєднанні. Я працював над старими системами, де вони не відповідали, і це був кошмар,

Жодна конвенція не діє у всіх випадках, тож навіщо її взагалі мати? Використовуйте здоровий глузд ...

наприклад, для таблиці з самопосиланням, коли є більше одного стовпця FK, який самостійно посилається на ПК однієї таблиці, ви повинні порушити обидва "стандарти", оскільки два стовпці FK не можуть бути названі однаковими ... наприклад , Таблиця співробітників з EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, ...

Я згоден, що між ними мало що вибрати. Для мене набагато важливішою справою будь-якого стандарту є «стандартна» частина.

Якщо люди починають "робити власну справу", вони повинні бути нанизаними їх сітками. ІМХО :)

Чи розглядали ви наступне?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

Конвенція, яку ми використовуємо там, де я працюю, досить близька до точки А, за винятком того, що ми називаємо таблиці у формі множини (тобто "службовці") і використовуємо підкреслення між таблицею та назвою стовпців. Вигода від цього полягає в тому, що для посилання на стовпець це або "співробітники _ ідентифікатор", або "службовці.id", залежно від способу доступу до нього. Якщо вам потрібно вказати, з якої таблиці надходить стовпець, "службовці.employees _ id", безумовно, зайві.

Якщо ви дивитесь на код програми, а не лише запити до бази даних, деякі речі мені здаються зрозумілими:

1. Визначення таблиці зазвичай безпосередньо відображаються в класі, який описує один об'єкт, тому вони повинні бути єдиними. Щоб описати колекцію об'єкта, я зазвичай додаю "Масив" або "Список" або "Колекція" до однини, оскільки це чіткіше, ніж використання множини, вказує не тільки на те, що це колекція, але і на яку колекцію Це є. У такому погляді я бачу назву таблиці не назвою колекції, а назвою типу об'єкта, яким вона є колекція. DBA, який не пише код програми, може пропустити цей пункт.

2. Дані, з якими я маю справу, часто використовують "ідентифікатор" для неключових ідентифікаційних цілей. Для усунення плутанини між ключовими "ідентифікаторами" та нелюковими "ідентифікаторами", для імені первинного ключа ми використовуємо "Ключ" (ось що це, чи не так?) З префіксом назви таблиці або абревіатурою назва таблиці. Ця префіксація (і я зарезервую це лише для первинного ключа) робить ім'я ключа унікальним, що особливо важливо, оскільки ми використовуємо імена змінних, які є такими ж, як імена стовпців бази даних, і більшість класів мають батьківський, визначений іменем батьківський ключ. Це також потрібно, щоб переконатися, що це не зарезервоване ключове слово, яке є лише "Ключ". Щоб полегшити постійне узгодження імен ключових змінних та передбачити програми, які виконують природні з'єднання, іноземні ключі мають те саме ім’я, яке використовується в таблиці, в якій вони є первинним ключем. Я не раз стикався з програмами, які працюють набагато краще, використовуючи природні з'єднання. На цьому останньому моменті я визнаю проблему із таблицями самовідсилань, якими я користувався. У цьому випадку я б зробив виняток із правила іменування зовнішнього ключа. Наприклад, я б використовував ManagerKey як зовнішній ключ у таблиці Співробітник, щоб вказати на інший запис у цій таблиці.

Мені подобається конвенція №2 - досліджуючи цю тему і знаходячи це питання, перш ніж розміщувати своє, я зіткнувся з проблемою, де:

Я вибираю * з таблиці з великою кількістю стовпців і приєдную його до другої таблиці, яка також має велику кількість стовпців. В обох таблицях стовпчик "id" в якості основного ключа, і це означає, що я повинен спеціально виділити кожен стовпець (наскільки я знаю), щоб зробити ці два значення унікальними в результаті, тобто:

SELECT table1.id AS parent_id, table2.id AS child_id

Хоча використання умовного режиму №2 означає, що я все ще матиму кілька стовпців у результаті з тим самим іменем, тепер я можу вказати, який саме ідентифікатор мені потрібен (батько чи дитина), і, як запропонував Стівен Хьюїг, USINGзаява спрощує справи.

Я завжди використовував userId як ПК на одній таблиці, а userId на іншій таблиці - як FK. Я серйозно замислююся над тим, щоб використовувати userIdPK та userIdFK як імена для ідентифікації одного від іншого. Це допоможе мені швидко визначити PK та FK при перегляді таблиць, і, здається, він очистить код при використанні PHP / SQL для доступу до даних, що полегшує розуміння. Особливо, коли хтось інший дивиться на мій код.

Я використовую конвенцію №2. Я зараз працюю зі застарілою моделлю даних, де я не знаю, що означає дана таблиця. Де шкода бути багатослівним?

Як щодо називання зовнішнього ключа

role_id

де роль - це роль, на яку посилається суб'єкт господарювання, має відносну таблицю. Це вирішує питання про рекурсивну посилання та декілька fks до однієї таблиці.

У багатьох випадках буде ідентичним імені згаданої таблиці. У цьому випадку вона стає однаковою для однієї з ваших пропозицій.

У будь-якому випадку довгі аргументи Хавіна - це погана ідея

"Де в" співробітник INNER JOIN order ON ON order.employee_id = службовець.id ", чи є потреба в додатковій кваліфікації?".

Немає необхідності в додатковій кваліфікації, оскільки кваліфікація, про яку я говорив, уже є.

"причина, по якій бізнес-користувач посилається на ідентифікатор замовлення або ідентифікатор працівника, полягає у наданні контексту, але на рівні бази даних у вас вже є контекст, оскільки ви відповідаєте таблиці".

Помоліться, скажіть мені, якщо стовпець має ім'я "ID", то як саме виконується те "порівняння [sic] з таблицею", якщо тільки не кваліфікувати це посилання на стовпець ID точно так, як я говорив?