Які найкращі практики щодо таблиць пошуку у реляційних базах даних?

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

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

• party_code_idn, що містить цифрові значення, що генеруються системою, і (бракує значення доменного бізнесу ) працює як сурогат для реального ключа.
• party_code, це справжній або "природний" ключ таблиці, оскільки він підтримує значення, що мають конотації ділових доменів .

Скажімо, що така таблиця зберігає дані, які випливають:

 +----------------+------------+
 | party_code_idn | party_code |
 +----------------+------------+
 |              1 | Republican |
 |              2 | Democratic |
 +----------------+------------+

party_codeКолона, яка зберігає значення «Республіканський» і «демократична», будучи реальним ключем таблиці, встановлюється з обмеженням UNIQUE, але необов'язково , додав party_code_idnі визначив його як PK таблиці (хоча, говорячи логічно , party_codeможе працювати як ПЕРШИЙ КЛЮЧ [ПК]].

Питання

Які кращі практики для вказуючи на підстановки значень з таблиць транзакцій ? Чи слід встановлювати зовнішні посилання (FK) або (a) безпосередньо на природне та значуще значення або (b) на сурогатні значення?

Варіант (a) , наприклад,

 +---------------+------------+---------+
 | candidate_idn | party_code |  city   |
 +---------------+------------+---------+
 |             1 | Democratic | Alaska  |
 |             2 | Republican | Memphis |
 +---------------+------------+---------+

має такі властивості ¹ :

1. Читається для кінцевого користувача (+)
2. Легко ввозити-експортувати через всі системи (+)
3. Важко змінити значення, оскільки воно потребує модифікації у всіх посилаються таблицях (-)
4. Додавання нового значення не дорого (=)

Я думаю, що це майже як " пройти за значенням ", щоб зробити аналогію з викликом функції в жаргоні програмування додатків.

Варіант (b) , наприклад,

 +---------------+----------------+---------+
 | candidate_idn | party_code_idn |  city   |
 +---------------+----------------+---------+
 |             1 |              1 | Alaska  |
 |             2 |              2 | Memphis |
 +---------------+----------------+---------+

має властивості нижче:

1. Не читабельний для кінцевого користувача (-)
2. Складно імпортувати-експортувати, оскільки нам потрібно скасувати його (-)
3. Легко змінювати значення, оскільки ми зберігаємо лише посилання в таблиці транзакцій (+)
4. Додавання нового значення не дорого (=)

Він дуже схожий на " пройти посилання ", якщо порівнювати функціональний виклик в програмуванні програми додатків.

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

_{1. Зверніть увагу , що +, -і =вказують на перевагу цих властивостей.}

Питання

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

Супутні ресурси

• Наскільки важливі таблиці пошуку?

• Кращі практики роботи з кодами або таблицями пошуку

• Таблиці найкращих практик пошуку таблиць або переліків БД

До IDN, я розумію , що ви означає IDENTITY, SEQUENCEабо AUTO_INCREMENTполе? Ви повинні подивитися тут і тут .

Зауважте, розділ 5 (Зловживання значеннями даних як елементи даних) першої посилання, під малюнком 10

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

Отже, цей експерт вважає, що вам слід «поважити» сурогатні ключі. Це дійсно основна методика SQL і не повинна створювати проблем у щоденному SQL. Здається, що на малюнку 10 є помилка - Sales_person у SalesData має бути сурогатним ключем (тобто числом), а не текстом. Я виводжу це з наведеної вище цитати.

Що варто уникати будь-якою ціною - спокуса (дуже поширена для початківців програмістів баз даних) вчинити помилку, викладену в розділі (1) Загальні таблиці пошуку. Це зазвичай називають підходом MUCK ( Massively Unified Code Key ) (не випадково :-), особливо Джо Челко , також саркастично відомим як OTLT - Єдина справжня таблиця пошуку ) і призводить до різного роду труднощів. Новачкам-програмістам здається, що один код / ​​пошук / будь-яка таблиця "чистіший" і буде ефективнішим, коли нічого не може бути далі від істини.

З другого посилання вище:

Нормалізація усуває зайві дані, тим самим полегшуючи завдання забезпечення цілісності даних значно простішим, але процес створення MUCK - це зовсім інше. MUCK не усуває зайвих даних, скоріше - це усунення того, що НАДАЄТЬСЯ бути зайвими таблицями, але як я продемонструю, менша кількість таблиць не дорівнює простоті.

Ви також можете ознайомитися з відповідною парадигмою EAV ( Entity Attribute Value ), з якою я тут маю справу .

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

Idn: 1
Name: Democrats
Code: D      (or DEM)

Код переноситься в транзакційні таблиці як іноземний ключ. Він короткий, зрозумілий і дещо незалежний від "реальних" даних. Поступові зміни імені не пропонують зміни коду. Однак, якщо республіканці будуть масово розпадатися , можливо, буде необхідна зміна коду з супутніми проблемами, які сурогатний ідентифікатор не виникне.

Цей стиль отримав назву кодування абревіатури. Я можу порекомендувати написання Селко щодо цього. У книгах Google є кілька прикладів. Пошук "кодування Celko".

Інші приклади: 2 або 3 букви кодувань для країн, 3-буквене кодування (GBP, USD, EUR) для кодів валют. Коротка, самоосмислювальна і не мінлива (і для них існує ISO).