У мене є транзакція .net із вставкою SQL до бази даних SQL Server 2005. У таблиці є первинний ключ ідентичності.
Коли в транзакції виникає помилка, Rollback()викликається. Вставки рядків відкочуються правильно, однак наступного разу, коли я вставляю дані до таблиці, ідентичність збільшується так, ніби відкат ніколи не відбувся. Отже, по суті, є прогалини в послідовності ідентичності. Чи є Rollback()спосіб повернути метод зниклої ідентичності?
Хіба я не підходжу до цього правильно?
Відповіді:
Якщо ви задумаєтесь, номер автоматичного збільшення не повинен бути транзакційним. Якщо іншим транзакціям доводилося чекати, щоб побачити, чи буде використаний автоматичний номер, чи він буде «відкатаний», вони будуть заблоковані наявною транзакцією за допомогою автоматичного номера. Наприклад, розгляньте мій код psuedo нижче з таблицею A, використовуючи поле автоматичного номера для стовпця ID:
User 1
------------
begin transaction
insert into A ...
insert into B ...
update C ...
insert into D ...
commit
User 2
-----------
begin transaction
insert into A ...
insert into B ...
commit
Якщо транзакція користувача 2 починається на мілісекунду після того, як користувач 1, то їх вставка в таблицю A повинна буде дочекатися завершення всієї транзакції користувача 1, лише щоб перевірити, чи було використано автоматичний номер з першої вставки в A.
Це особливість, а не помилка. Я б рекомендував використовувати іншу схему для генерації автоматичних чисел, якщо вам потрібно, щоб вони були жорстко послідовними.
Якщо ви залежате від того, що ваші цінності особистості є без погляду, тоді так - ви робите це неправильно. Вся суть сурогатного ключа в тому, щоб не мати ділового значення .
Ні, ні в якому разі не можна змінити цю поведінку (за винятком того, що ви прокатуєте власний автоінкремент і страждаєте від наслідків продуктивності блокування інших вставок).
Ви отримуєте прогалини у вашій послідовності, якщо ви DELETEтеж рядок.
Послідовності повинні бути унікальними, але вони не повинні бути послідовними. Той факт, що вони монотонно збільшуються, є лише випадковим впровадженням.
Наскільки я знаю, рядки для вставки вимагають автонумерації, а при відкатах це число назавжди втрачено. Якщо ви перебуваєте в залежності від того, яке саме число входить до послідовності, ви можете розглянути підхід, який ви використовуєте.
Усі інші плакати, які кажуть, що не хвилюйтеся з цього приводу та що вам слід отримати прогалини, мають рацію. Якщо число має значення бізнесу, і це значення не збивається з пробілами, тоді не використовуйте стовпець ідентифікатора.
До уваги, якщо з якоїсь причини Ви ВЖЕ хочете усунути прогалини, більшість баз даних мають спосіб перенаправити автоматичну нумерацію на номер, який Ви обрали. Це біль у дупі, і якщо вам здається, що це потрібно робити регулярно, ви точно не повинні використовувати поле з автоматичною цифрою / ідентифікацією, як зазначено вище. Але ось код, щоб зробити це на SQL-сервері:
DBCC CHECKIDENT ('Product', RESEED, 0)
Завдяки цьому таблиця продуктів починається з 1 (хоча якщо у вас є записи в таблиці, вона, очевидно, пропустить вже прийняті значення ідентифікатора.) Інші постачальники СУБД мають власний синтаксис, але ефект приблизно такий самий, отже, шукайте "повторно встановити ідентичність" або "повторно набрати число" у системних файлах довідки або інтернетах.
Знову ж таки: це для особливих випадків, а не для регулярного використання. Не вкладайте це в збережену процедуру і змушуйте нас усіх приходити туди.
Мухан намагається думати про це в контексті багатьох одночасних з'єднань, що виконують цю транзакцію, а не по одному. Хтось зазнає невдачі, а хтось досягне успіху. Ви хочете, щоб SQL Server сконцентрувався на запуску нових запитів у міру їх надходження, а не на підтримку стовпця ідентичності без пробілів. ІМО (прогалини в цінностях) - це, безумовно, те, на що не варто витрачати час.