Навіщо використовувати int як основний ключ таблиці пошуку?

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

Я розумію, що використання nvarchar (50), а не int, використовує більше місця, якщо він пов'язаний з таблицею з багатьма записами.

З іншого боку, використання прямого значення пошуку в основному врятувало б нас при об'єднанні. Я можу уявити, що це буде великим заощадженням, якщо приєднання завжди потрібно (ми працюємо над веб-додатком, і це враховує небагато).

Які переваги використання первинного ключа int (спеціально для таблиці пошуку), крім того, що це "стандартна річ"?

Відповідь на ваше запитання логічна, а не фізична - значення, яке ви шукаєте, може змінитися з ділових причин. Наприклад, якщо ви індексуєте своїх клієнтів за електронною адресою, що відбувається, коли зміниться електронна адреса? Очевидно, це не стосується всіх ваших таблиць пошуку, але переваги робити це однаково у всій програмі полягає в тому, що він спрощує ваш код. Якщо все ціле число → цілі відносини внутрішньо, ви охоплені.

Просто прочитайте ваш коментар Сенді - можливо, у цьому випадку вам дійсно потрібно обмежити перевірку , а не сторонній ключ / таблицю пошуку, наприклад:

create table icecream (flavour varchar(10))
go
alter table icecream add constraint ck_flavour check (flavour in ('Orange', 'Pista', 'Mango'))
go
insert into icecream (flavour) values ('Orange')
go
insert into icecream (flavour) values ('Vanilla')
go

Запустіть це, і ви отримаєте:

(1 row(s) affected)
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint "ck_flavour". The conflict occurred in database "GAIUSDB", table "dbo.icecream", column 'flavour'.
The statement has been terminated.

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

"Використання значення пошуку безпосередньо" - його біт суперечить фактичному призначенню таблиці пошуку. Чому ви тримаєте такий стіл? Якщо це не пошук.
Можливо, я неправильно зрозумів ваше запитання. Ось визначення таблиці пошуку від msdn

Таблиця пошуку використовується для відображення інформації з однієї таблиці на основі значення поля з іншим ключем в іншій таблиці. Наприклад, розглянемо таблицю замовлень у базі даних продажів. Кожен запис у таблиці Замовлення містить CustomerID із зазначенням того, який клієнт розмістив замовлення. CustomerID - це зовнішній ключ, який вказує на запис клієнта в таблиці Клієнтів. Представляючи перелік Замовлень (з таблиці Замовлення), можливо, ви захочете відобразити фактичне ім’я клієнта, на відміну від CustomerID. Оскільки ім’я клієнтів знаходиться в таблиці клієнтів, і ви представляєте дані з таблиці Замовлення, вам потрібно створити таблицю пошуку, яка приймає значення CustomerID у записі Замовлення та використовує це значення для навігації у відносинах та повернення більше читабельна, ім'я клієнта.

Чи можете ви визначити мету вашої таблиці пошуку? це використовується для зберігання деяких статичних даних, таких як наступні, і ці записи не є введенням записів інших таблиць?

Смаковий стіл

Orange  
Pista  
Mango

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

Оскільки ви кваліфікували своє запитання "спеціально для таблиці пошуку", відповідь, ймовірно, спрощено до "економії місця".

Я думаю, що якщо ви вилучите цей класифікатор, ваше питання стає "Навіщо використовувати сурогатні ключі над природними ключами?" Я написав наступне на підтримку сурогатних ключів:

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

Це багато в чому саме тому "стало стандартною справою". Невдалий бі-продукт полягає в тому, що люди кидають на сурогатний ключ і не думають, що таке ключі-кандидати ... Але зараз ми виходимо за ваше питання :)

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

Таблиця пошуку з первинним номером номера вимагає змінити лише значення в таблиці пошуку.

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

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