Що може бути недоліком завжди мати один цілий стовпець у якості основного ключа?

У межах однієї веб-програми, над якою я працюю, всі операції з базою даних абстрагуються за допомогою деяких загальних сховищ, визначених через Entity Framework ORM.

Однак для того, щоб мати просту конструкцію для загальних сховищ, усі залучені таблиці повинні визначати унікальне ціле число ( Int32у C #, intу SQL). Досі це завжди було ПК таблиці, а також IDENTITY.

Іноземні ключі широко використовуються, і вони посилаються на ці цілі стовпці. Вони потрібні як для послідовності, так і для генерації навігаційних властивостей ОРМ.

Прикладний рівень зазвичай виконує такі операції:

• початкове завантаження даних з таблиці (*) -SELECT * FROM table
• Оновлення -UPDATE table SET Col1 = Val1 WHERE Id = IdVal
• Видалити -DELETE FROM table WHERE Id = IdVal
• Вставити -INSERT INTO table (cols) VALUES (...)

Рідше операції:

• Об'ємна вставка - BULK INSERT ... into tableсупроводжується (*) всім завантаженням даних (для отримання створених ідентифікаторів)
• Масове видалення - це звичайна операція видалення, але "об'ємна" з точки зору ORM:DELETE FROM table where OtherThanIdCol = SomeValue
• Масове оновлення - це звичайна операція оновлення, але "об'ємна" з точки зору ORM:UPDATE table SET SomeCol = SomeVal WHERE OtherThanIdCol = OtherValue

* всі невеликі таблиці кешуються на рівні програми і майже всі SELECTsне доходять до бази даних. Типовою схемою є початкове навантаження та велика кількість INSERTs, UPDATEs та DELETEs.

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

Запитання: З точки зору DBA, чи є серйозні проблеми, з якими я можу зіткнутися через обмеження в дизайні таблиці?

[EDIT]

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

1. Поточна специфікація додатків - я не згадував про поточну веб-програму, тому що хочу зрозуміти, чи можна використовувати модель для інших додатків. Однак мій конкретний випадок - це програма, яка витягує багато метаданих із DWH. Вихідні дані досить безладні (денормалізовані дивним чином, які мають деякі невідповідності, відсутність природного ідентифікатора у багатьох випадках тощо), і мій додаток генерує чітке відокремлене ціле. Також багато згенерованих ідентифікаторів ( IDENTITY) відображаються, щоб користувач міг використовувати їх як бізнес-ключі. Це, крім масштабного рефакторингу коду, виключає використання GUID .

2. "вони не повинні бути єдиним способом однозначно визначити ряд" (Аарон Бертран ♦) - це дуже хороша порада. Усі мої таблиці також визначають УНІКАЛЬНЕ ОБМЕЖЕННЯ, щоб переконатися, що копії бізнесу не дозволені.

3. Дизайн, керований додатком та дизайном, керований базами даних - вибір дизайну обумовлений цими чинниками

   1. Обмеження Entity Framework - кілька ПК у стовпцях дозволено, але їх значення не можна оновити

   2. Спеціальні обмеження - наявність єдиного цілого ключа значно спрощує структури даних та не-SQL-код. Напр .: усі списки значень мають цілий ключ та відображені значення. Що ще важливіше, це гарантує, що будь-яку таблицю, позначену для кешування, можна буде помістити у Unique int key -> valueкарту.

4. Складні запити вибору - цього майже ніколи не відбудеться, оскільки всі невеликі (<20-30K записів) таблиці таблиць кешуються на рівні програми. Це робить життя трохи складніше при написанні коду програми (складніше писати LINQ), але база даних потрапляє набагато приємніше:

   1. Перегляди списку - не SELECTзавантажуватиме запитів під час завантаження (усе є кешованим) або запитів, які виглядають так:

      SELECT allcolumns FROM BigTable WHERE filter1 IN (val1, val2) AND filter2 IN (val11, val12)

      Усі інші необхідні значення отримуються через пошук кешу (O (1)), тому складні запити не будуть генеровані.

   2. Редагувати представлення даних - генерувати SELECTтакі заяви:

      SELECT allcolumns FROM BigTable WHERE PKId = value1

(усі фільтри та значення ints)

Крім додаткового простору на диску (і, в свою чергу, використання пам'яті та вводу / виводу), насправді немає жодної шкоди для додавання стовпця ІДЕНТИЧНОСТІ навіть до таблиць, які не потребують такої (приклад таблиці, яка не потребує стовпця ІДЕНТИЧНОСТІ) - це проста таблиця переходу, наприклад, зіставлення користувача до його дозволів).

Я заперечую проти того, щоб сліпо додавати їх до кожної таблиці в блозі з 2010 року:

• Погані звички бити: ставити стовпець ІДЕНТИМИТЕТ на кожен стіл

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

З мого досвіду, головна і переважна причина використання окремого ідентифікатора для кожної таблиці полягає в наступному:

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

Тоді, з точки зору DBA, речі, які роблять БД повільним або роздутим, - це, звичайно, не 4 байти (або що завгодно) у рядку, але такі речі, як неправильні чи відсутні індекси, забуті перебудови таблиці / індексу, неправильні параметри настройки RAM / таблиці. , нехтуючи використанням змінних прив'язки тощо. Вони можуть уповільнити БД коефіцієнтами 10, 100, 10000 ... не додатковий стовпець ідентифікатора.

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

Примітка: зауважте, що вам не потрібен окремий ідентифікатор для n:mтаблиць асоціацій, оскільки для таких таблиць ідентифікатори асоційованих об'єктів повинні утворювати первинний ключ. Контрприклад - це дивна n:mасоціація, яка дозволяє безліч асоціацій між тими ж двома сутностями з будь-якої химерної причини - їм тоді потрібен власний стовпець ідентифікатора, щоб створити ПК. Там є ОРЗ бібліотеки , які не можуть обробляти первинні ключі декількох стовпців , хоча, так що буде привід бути поблажливим з розробниками, якщо вони повинні працювати з такою бібліотекою.

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

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

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

На мій досвід роботи з різними базами даних, первинний ключ Integer завжди кращий, ніж програми, у яких зовсім не визначені ключі. Або у вас є ключі, які з'єднують півдесятка стовпчиків варчарів незграбними способами, не логічними ... (зітхання)

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

Я б сказав, що ціле ПК не збирається вас кусати, якщо ви не плануєте об'єднати дані з окремих джерел або у вас можуть бути дані, що виходять за рамки ваших цілих розмірів - це все весело та ігри, поки у вас не залишиться місця для вставок .

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

Відклавши:

• Релігійні війни (сурогат Google проти природного ключа)
• Окреме питання про те, які кластерні індекси визначити у ваших таблицях
• Життєздатність кешування всіх ваших даних

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

У вас є кілька факторів, які допоможуть вам орієнтуватися,

1. Визначення та специфікація.

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

2. Унікальність.

   Для особистої розумності, приєднання та функціонування бази даних вищого рівня вам знадобиться: (a) унікальний стовпець, (b) унікальна серія стовпців

   Усі досить нормалізовані схеми (1NF) забезпечують одне з наступних. Якщо їх немає, ви завжди повинні їх створювати. Якщо у вас є рейтинг людей, призначених на волонтерську неділю, і він включає прізвище та ім'я, ви хочете дізнатися, коли у вас є два Джо Бобса.

3. Впровадження та оптимізація.

   Int має тенденцію бути невеликою формою даних, яка швидка для порівняння та рівності. Порівняйте це з рядком Unicode, порівняння якого може залежати від місцевості (місця та мови). Збереження 4242 в рядку ASCII / UTF8 - 4 байти. Зберігаючи його як ціле число, воно вміщується в 2 байти.

Отже, якщо мова йде про мінуси, у вас є кілька факторів.

1. Плутанина і неоднозначність.

   1. Запис блогу @Aaron Bertrand підсумовує це добре. Це не самодокументування, щоб мати OrderID за специфікацією та завданням, а потім накладати " OrderID " через реалізацію бази даних. Іноді доводиться уточнити це або створити конвенцію, але це, ймовірно, додасть плутанини.

2. Космос.

   Цілі особи все ще додають простір до рядка. І якщо ви не використовуєте їх, немає ніякої мети.

3. Кластеризація.

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