Іноземні ключі - посилання за допомогою сурогату чи природного ключа?

Чи є найкраща практика щодо того, чи повинен зовнішній ключ між таблицями посилатися на природний ключ або сурогатний ключ? Єдине обговорення, яке я насправді знайшов (якщо не вистачає мого google-fu) - це відповідь Джека Дугласа в цьому питанні , і його міркування здаються мені звуковими. Мені відомо про обговорення поза тим, що правила змінюються, але це було б щось, що потрібно враховувати в будь-якій ситуації.

Основна причина запитання полягає в тому, що у мене є застаріле додаток, який використовує FK з природними ключами, але сильний поштовх від розробників перейти до OR / M (NHibernate в нашому випадку), а вилка вже видала порушуючи зміни, тому я хочу відсунути їх назад на трасі за допомогою природного ключа, або перенести застарілий додаток, щоб використовувати сурогатні клавіші для FK. Моя кишка каже відновити оригінальний FK, але я чесно не впевнений, чи це справді правильний шлях.

Більшість наших таблиць вже мають сурогатний та природний ключ, який уже визначений (хоча унікальне обмеження та ПК), тому необхідність додавання додаткових стовпців для нас не є проблемою. Ми використовуємо SQL Server 2008, але сподіваюся, що це є загальним для будь-якої БД.

Ні SQL, ні реляційна модель не порушуються сторонніми ключами, які посилаються на природний ключ. Насправді, посилання на природні ключі часто значно покращує продуктивність. Ви були б здивовані, як часто потрібна інформація повністю міститься в природному ключі; посилання на те, що ключ торгує приєднанням для ширшої таблиці (і, отже, зменшує кількість рядків, які ви можете зберігати на одній сторінці).

За визначенням, потрібна вам інформація завжди повністю міститься в природному ключі кожної таблиці "пошуку". (Таблиця пошуку термінів неформальна. У реляційній моделі всі таблиці є лише таблицями. Таблиця поштових індексів США може мати рядки, які виглядають приблизно так: {AK, Alaska}, {AL, Alabama}, {AZ, Arizona} і т. д. Більшість людей називають цю таблицю пошуку.)

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

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

По-перше, ви здивуєте людей. Хоча я зазвичай сильно лобіюю « Принцип найменшого сюрпризу» , це одна ситуація, коли я не заперечую над дивними людьми. Коли проблема полягає в тому, що розробників дивує логічне використання сторонніх ключів, рішення - це освіта, а не перепроектування.

По-друге, ORM зазвичай не розроблені навколо реляційної моделі, і вони іноді втілюють припущення, які не відображають найкращої практики. (Насправді вони часто здаються спроектованими без будь-якого введення даних професіонала БД.) Потрібна кількість ідентифікаційного номера в кожній таблиці - одне з цих припущень. Ще один припущення, що програма ORM "володіє" базою даних. (Отже, безкоштовно створювати, видаляти та перейменувати таблиці та стовпці.)

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

Вилка, яка вводить порушення змін, повинна бути стопором.

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

Інші відповідні відповіді: У схемі баз даних заплутані

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

Далі за 30 років я використовую різноманітні бази даних з багатьох тем, справжній природний ключ часто досить рідкісний. Речі нібито унікальні (SSN) - ні, речі, які є унікальними в певний час, можуть стати неповторними пізніше, а деякі речі, такі як адреси електронних листів та номери телефонів, можуть бути унікальними, але вони можуть бути використані для різних людей пізніше дата. Звичайно, деякі речі просто не мають такого унікального ідентифікатора, як імена людей та корпорацій.

Щодо уникнення приєднання за допомогою природного ключа. Так, це може прискорити вибрані оператори, які не потребують з'єднання, але це призведе до того, що місця, де вам все ще потрібно з'єднання, будуть повільнішими, оскільки int приєднання, як правило, швидше. Це також, ймовірно, сповільнить вставки та видалення та спричинить проблеми з ефективністю оновлень, коли ключ зміниться. Складні запити (які все-таки повільніші) будуть ще повільнішими. Тож прості запити швидші, але звітування та складні запити та багато дій проти бази даних можуть бути повільнішими. Це акт балансування, який може підходити так чи інакше залежно від того, як запитується ваша база даних.

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

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

Особа, Роль, Персона Роль

Поточне правило бізнесу говорить про те, що особа має одну роль. Ви складаєте таблицю, яка пов'язує особу та роль, де PersonRole (PersonName, PersonBirthDate, PersonMotherMaidenName, ..., RoleCode)

Тепер ви справжній пурист, коли мова йде про природні ключі! Якщо серйозно, що робити, якщо орган вирішить, що людина тепер може взяти на себе кілька ролей? Які наслідки підтримки змін у бізнес-потребах є нижчими напрямками?