Я думаю, що потреба - це дуже сильне слово, і в строгому сенсі таблиці, ймовірно, не потребують сурогатних ключів .
Однак, якби це була моя база даних, я б, мабуть, додав сурогатні ключі в будь-якому випадку. Я не обов'язково хочу, щоб дизайн моєї бази даних залежав від групи третіх сторін (IATA, ISO), незалежно від того, наскільки стабільні їх стандарти. Або я не хочу взагалі залежати від певного стандарту (чи існують інші стандарти коду валюти? Я не знаю). Я б, мабуть, моделював свої таблиці з сурогатними ключами, як-от так:
+-------------------------+ +------------------------+
|Airport | |Country |
|-------------------------| |------------------------|
|airport_id int (PK)| |country_id int (PK) |
|iata_airport_code string | |iso_country_code string |
|icao_airport_code string | +------------------------+
|faa_identifier string |
|address string |
|name string |
+-------------------------+
+-------------------------+
|Currency |
|-------------------------|
|currency_id int (PK) |
|iso_currency_code string |
|name string |
+-------------------------+
Іншими словами, якщо ці стандартні коди не є важливими для моєї програми, я б не використовував їх як ПК моїх таблиць. Вони просто етикетки. Більшість моїх інших таблиць, мабуть, матимуть сурогатні ключі в будь-якому випадку, і ця настройка додасть послідовності моїй моделі даних. Вартість "додавання" сурогатних ключів мінімальна.
Оновлення на основі деяких коментарів:
Не знаючи контексту прикладних таблиць, неможливо знати, наскільки важливі речі, такі як коди аеропортів IATA, для програми, що використовує базу даних. Очевидно, що якщо коди IATA мають центральне значення та використовуються повсюдно протягом усієї програми, після правильного аналізу може бути правильним рішення використовувати коди як ПК в таблиці.
Однак, якщо таблиця є лише таблицею пошуку, яка використовується в кількох куточках програми, відносна важливість кодів IATA може не виправдовувати такого помітного місця в інфраструктурі бази даних. Звичайно, можливо, вам доведеться зробити додаткове приєднання в декількох запитах тут і там, але це зусилля може бути банальним порівняно з зусиллями, необхідними для проведення досліджень, щоб гарантувати, що ви повністю розумієте наслідки внесення кодів IATA в поле первинного ключа. У деяких випадках мене не тільки не хвилює, але мені не хочеться піклуватися про коди IATA. Коментар @James Snell нижче - прекрасний приклад того, що я, можливо, не хотів би турбуватися про вплив на ПК моїх таблиць.
Також важлива послідовність в дизайні. Якщо у вас є база даних з десятками таблиць, у яких всі послідовно розроблені сурогатні ключі, а потім кілька таблиць пошуку, які використовують сторонні коди як ПК, це вводить невідповідність. Це зовсім не погано, але воно вимагає додаткової уваги в документації та такому, що не може бути гарантовано. Вони шукають таблиці на користь, просто використання сурогатного ключа для послідовності - це цілком добре.
Оновлення на основі подальших досліджень:
Гаразд, цікавість мене трохи вкусила, і я вирішив зробити кілька цікавих кодів кодів аеропортів IATA для розваги, починаючи з посилань, наведених у питанні.
Як виявляється, коди IATA не є настільки універсальними та авторитетними, як з'ясовує питання. Відповідно до цієї сторінки :
У більшості країн у своїх офіційних аеронавігаційних публікаціях використовуються чотиризначні коди ICAO , а не IATA.
Крім того, коди IATA та коди ICAO відрізняються від ідентифікаційних кодів FAA , які є ще одним способом ідентифікації аеродромів.
Моя суть у доведенні цих питань полягає не в тому, щоб почати дебати про те, які коди є кращими або універсальнішими, більш авторитетними або всебічнішими, а точно показати, чому проектування структури вашої бази даних навколо довільного стороннього ідентифікатора - це не те, що я б вирішив зробити , якщо не було конкретної ділової причини для цього .
У цьому випадку я вважаю, що моя база даних буде краще структурованою, стабільнішою та гнучкішою, відмовившись від IATA-кодів (або будь-якого третьої сторони, потенційно мінливого коду) як основного кандидата та використовуючи сурогатний ключ. Роблячи це, я можу відмовитись від будь-яких можливих підводних каменів, які можуть з'явитися через вибір первинного ключа.
