Стовпці особи або UDF, які явно створюють унікальний ідентифікатор?

Я в середині дискусії про те, чи краще PRIMARY KEYвикласти зі стовпців ідентичності , наших з АДС, які явно генерують унікальний ідентифікатор.

• Я сперечаюся за стовпцем особи.
• Мій партнер сперечається щодо генерування значень вручну, стверджує він
  • помістивши UDF на іншу таблицю, де ми можемо мати АДС
    • заблокувати ресурс
    • збільшити таблицю ID з одним полем називається ID_Valueшляхом1
    • використовувати це як глобальний унікальний ідентифікатор
  • Або попросіть таблицю зробити під id+1час вставлення
  • Що простіше переміщувати дані між серверами та / або середовищами, що не мають обмеження ідентифікації; перехід від однієї БД, де є дані, до іншої аналогічної БД з можливістю промовляти дані про постановку або манекени. Для тестування в невиробництві ми можемо захотіти перенести всі записи від вчорашнього дня до постановки на тестування.

Яка реалізація має більше сенсу?

Ваш колега - ідіот.

Рішення не буде масштабованим, UDF не є одночасною (та сама причина, що і ця ). І як ви маєте справу з багаторядковими вставками: для цього потрібен дзвінок у списку UDF на рядок

І міграція до інших RDBMS не трапляється часто в реальному житті ... ви можете також не використовувати SQL Server зараз і використовувати послідовності в Oracle і сподіваєтесь, що ви не мігруєте геть.

Редагувати:

У вашому оновлення зазначено, що переміщення даних призначене для оновлення баз даних невиробничих.

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

Або використовувати процеси: ми щодня оновлюємо нашу тестову систему від виробництва, що повністю уникає проблеми. (І забезпечує наше відновлення резервної копії продукту також)

Використовуйте значення ідентичності. Генерування власної таблиці послідовностей та значень послідовностей зажадає великі накладні витрати та спричинить багато блокування та блокування при спробі генерування чисел.

Ідентичність існує з причини, використовуйте її.

Коли SQL Denali вийде, він буде підтримувати послідовності, які будуть більш ефективними, ніж ідентичність, але ви не можете створити щось більш ефективне самостійно.

Що стосується переміщення записів з одного середовища в інше, або увімкніть IDENTITY_INSERT під час вставки, або поставте прапорець у SSIS.

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

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

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

Ви завжди можете створити "супер таблицю", яка використовує ідентичність як ПК та містить стовпчик типу та будь-яку іншу інформацію. Коли вам потрібен новий ідентифікатор (якщо припустити, що ви маєте на увазі унікальний IDS для різних таблиць), просто вставте в цю таблицю та захопіть, SCOPE_IDENTITY()а потім вставте у фактичну потрібну вам таблицю.

В основному ви створюєте таблицю: MasterID з ідентифікаційним ПК, коли вам потрібно вставити рядок у таблицю1, INSERT INTO MasterIDsі отримати ідентифікацію, сформовану цим рядком, використовуючи, SCOPE_IDENTITY()а потім вставити в таблицю1, використовуючи це значення як ПК.

Таблиця1 матиме int PK без ідентичності. Ви б виконали той самий процес, щоб вставити його в Table2 тощо. Нехай SQL Server керує значеннями ідентичності в таблиці MasterIDs , які ви можете використовувати в інших таблицях. MasterID можуть містити інші таблиці, наприклад тип (щоб ви могли знати, яка таблиця, Table1 або Table2 тощо) використовує це значення ідентичності.

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

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

Щойно я закінчив роботу, де я замінив identityстовпчик SQL Server нормальним intполем і сам контролював розподіл Id.

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

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

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

Я використовував посвідчення років і серйозно розглядав питання про заміну ідентифікаційного номера на UNIQUEIDENTIFIER. Це кошмар, коли потрібно змінити тип даних, якщо хтось спроектував це компактний db і кошмар, якщо вам потрібно додати ідентифікацію до стовпця, також ви не можете оновити стовпчик ідентичності. Уявіть, що ви помістили int, і ваша база даних зростає за 2 мільярди записів, знову кошмар, щоб змінити (враховуйте FK)! Зміна чого-небудь з особистістю - це кошмар і не є доброзичливою, якщо ви не поставите bigint! UNIQUEIDENTIFIER vs Identity = зручність і надійність порівняно, можливо, помітне поліпшення продуктивності (не зробили еталон).

Оновлення: Після того, як я бачив це я точно схиляюся до UniqueIdentifier. Це не свідчить про реальну користь ідентичності bigint та купу переваг для UNIQUEIDENTIFIER! Різні версії SQL Server можуть мати різний результат. Є просто краса в тому, щоб мати унікальний ідентифікатор у всіх базах даних та системах (надійність)! Переміщуйте, копіюйте, трансформуйте дані за вашим бажанням! https://www.mssqltips.com/sqlservertip/5105/sql-server-performance-comppare-int-versus-guid/