Первинний ключ символів проти цілого числа

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

Які наслідки для продуктивності використання символьного поля в якості основного ключа, а не цілого числа?

Я використовую MySQL, якщо це має значення.

[Редагувати] У
ці таблиці пошуку нові записи додаються нечасто. Вони підтримуються вручну, а також створені символьні клавіші. Ось приклад:

      CUISINES
 ID      Description
-----  --------------
CHNSE  Chinese
ITALN  Italian
MXICN  Mexican

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

Що ще важливіше, це залежить від використання, до якого ви поставите первинний ключ. Цілі серіали мають перевагу в тому, що вони прості у використанні та реалізації. Вони також, залежно від конкретної реалізації методу серіалізації, мають перевагу в швидкості отримання , оскільки більшість баз даних просто зберігають серійний номер у фіксованому місці, а не отримують його з Select max(ID)+1 from fooльоту.

Постає питання: як клавіша з 5 символів представляє "значуще значення" для вас та програми? Як створюється це значення і чи займає це більше чи менше часу, ніж пошук збільшення серійного номера. Хоча в деяких цілих числах зберігається тривіальна кількість місця, переважна більшість систем проігнорує цю економію місця.

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

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

Якщо у мене є 10 000 рецептів, чи не починає складатися різниця між 5-символьним та 20-символьним ключем?

Простір дешевий . Якщо ви говорите 10 000 000 рецептів, над якими ви виконуєте операції OLAP, можливо, можливо. Завдяки 10-кратним рецептам, ви дивитесь на 150 тис. Місця.

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

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

Я думаю, що для рідко змінених таблиць немає проблеми з продуктивністю. Можливо, у вас будуть проблеми з дизайном в майбутньому. Я пропоную вам не використовувати бізнес-дані як основний ключ через зміни бізнесу. Використовуйте будь-який додатковий первинний ключ, щоб "зв’язати" таблиці у вашій моделі. Будь-які зміни в бізнесі НЕ вплинуть на пов'язані з цією таблицею.

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

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

Якщо у вас є багато послідовних даних (файли журналів, часові ряди, аналітика, текстові чи мовленнєві корпуси), які мають посилання (зв’язки) на будь-яку з ваших таблиць пошуку, ви побачите, що місце для зберігання є критичним для швидкості запитів, незважаючи на @ Правильний аналіз Ballsun-Stanton про те, наскільки дешевий простір у доларах . Оскільки більшість часу запитів (для послідовних даних) витрачається на читання диска, простір не є дешевим за часом (як відсоток від загального часу запиту). Отже, якщо ваш RDB автоматично та ефективно стискає / розтискає всі зовнішні ключі (клавіші до відповідних записів), ви хочете, щоб усі ваші клавіші були Int, які є найбільш ефективними щодо дискового простору (та швидкості читання) на одиницю інформації зміст (ентропія). FYI MyISAM в MySql встановлює обмеженняпро те, що можна робити зі стислими рядками даних (лише читання). Іншими словами, автоматично нарощені цілі числа вже стискаються, наскільки це теоретично можливо , враховуючи низьке обмеження мінімального розміру в більшості цілих полів БД. І це стиснення відбувається без:

1. штраф за час стиснення / декомпресії запиту
2. штраф за час запиту читання диска
3. обмеження лише для читання або інші БД щодо стислих записів даних або ключів

Існує причина, чому такі популярні, ефективні ORM, як Django, за замовчуванням для автоматичного збільшення цілих чисел для ПК, і чому інші питання SO прийшли до того ж висновку.