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

Це мене клопоче вже деякий час. Здебільшого, коли мова йде про зберігання даних у таких структурах, як хештелі, програмісти, книги та статті, наполягають, що індексація елементів у зазначених структурах за значеннями String вважається поганою практикою. Але поки що я не знайшов жодного такого джерела, щоб також пояснити, ЧОМУ це вважається поганою практикою. Це залежить від мови програмування? За основу? Про реалізацію?

Візьміть два прості приклади, якщо це допомагає:

Таблиця, схожа на SQL, де рядки індексуються первинним ключем String.

Словник .NET, де ключами є рядки.

Це в основному стосується двох речей:

1) Швидкість пошуку (де, наприклад, цілі числа проходять набагато краще)

2) розмір індексів (де рядкові індекси вибухнуть)

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

PS Може не стосуватися вашого питання, але Посібники вважаються поганими і для ключів бази даних (16 байт Guid проти 4-байтових цілих чисел). На великих обсягах даних посібники сповільнюють пошук.

Є ще одна проблема використання рядків як клавіш або, точніше, використання рядкових літералів як ключів, відміняючи чисті причини ефективності / ефективності. Друкарські помилки. Якщо ви використовуєте рядкові літерали як ключі в словнику, ви налаштовуєте себе на неприємний сюрприз, коли людина "ReceiverId"стає а "RecieverId". Налаштуйте константи для зберігання ключових значень та повторного використання їх щоразу, коли ви отримуєте доступ до словника.

Можна сказати, тривіально і очевидно, але надзвичайна кількість прикладів .NET коду в Інтернеті використовує рядкові літерали, що поширюють цю сумнівну практику. Тут особливо винним є ASP.NET з усіма сесіями, ViewStates та QueryParams, що розповсюджуються по всій кодовій базі.

Тут є багато компромісів. Насправді я часто використовую рядкові клавіші, але часто я включаю сурогатні вторинні ключі для приєднання (очевидно, це було б навпаки, якби я використовував MySQL). Є випадки, коли я цього не роблю.

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

З двох причин я зазвичай додаю сурогатні ключі:

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

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

У тих випадках, коли природний ключ є остаточним, одинарним стовпцем та текстом, я зазвичай приєднуюся до рядкового ключа. Моя причина для цього полягає в тому, що це часто уникає приєднань під час пошуку. Найбільш поширене використання - це надання належного дизайну db навколо випадку використання типів enum. У більшості випадків вони не потребують додаткового з'єднання для звичайних запитів. Отже, де це так, строкові клавіші як клавіші з'єднання мають ідеальний сенс.

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

Щодо того, чому за замовчуванням будуть цілі клавіші, я не думаю, що це лише питання розміру індексу. Велике питання - управління ключами. Оскільки ключ довільний і ви можете мати справу з мільйонами записів, ви повинні мати спосіб створення унікальних рядків. Бувають випадки, коли люди використовують для цього UUID, але існує ненульовий шанс зіткнення UUID, і коли зберігаються мільярди записів, цей шанс стає достатньо високим, який можна насправді побачити, тоді як шанс зіткнення з інкремованими цілими типами дорівнює нулю за визначенням.

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

Сама по собі це не погана ідея, як правило, з 20/20 заднього огляду поганий дизайн-компроміс. Гнучкість та діапазон струн проти додаткових витрат та складності.

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

Ви якимось чином отримали неправильні дані з Hashtable.

Ви мали на увазі "Телефон дня" або "Вечірній телефон"?

або

Ви мали на увазі 1234567 чи 1234576?

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

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

рядовий ключ матиме сенс, якщо мова йде про таблицю пошуку з приблизно 10-100 записами коротких рядків; пов'язані дані є більш читабельними + наприклад, відстеження змін (числовий / ідентифікатор і порівняння рядка, наприклад, "Адміністратор"); btw, база даних ASP.NET членства використовує рядкові ключі для AspNetRoles.