Последовательности в сиквеле

К заметке о том, как можно организовать последовательность (счетчик) уникальных целочисленных значений на MS SQL Server впору добавлять конкурс на самую шедевральную реализацию. Так сказать, "шедевры" мировой софтостроительной архитектуры.

Начну с такого примера.

Имеется таблица типа "помойка справочников", привнесенная в MS SQL разработчиками из времен Клиппера, когда ссылочную целостность жоооостко кодировали непосредственно в приложении. Основная структура состоит из трех строковых полей: код справочника, код значения, значение.

Для счетчиков выбран код справочника "1", коды величин содержат однотипные внутренние константы - имена счетчиков типа "NUM001", а собственно сама текущая величина счетчика хранится в строковом поле значения в виде "ПРЕФИКС;ЗНАЧЕНИЕ".

Что делает приложение. Считывает текущее значение счетчика. Анализирует строку, выделяя префикс и величину. Переводит величину из строки в целое. Увеличивает его на 1. Формирует новое значение строки: префикс + разделитель + значение (из целого снова в строку). И записывает все это обратно в базу.

Кроме сиих магических манипуляций со строкой, вначале делается попытка заблокировать запись через SELECT FROM Table (UPDLOCK). Мысль неплохая, но, к сожалению, это делается вне контекста транзакции. То есть можно было и не стараться.

На вопрос: "У вас несчастные случаи на стройке были""У вас конфликтов нарушения первичного ключа не было?" был дан самый оригинальный ответ за всю мою практику: "Они нам мешали делать каскадные обновления в связанных таблицах и мы их удалили".

Занавес...

P.S. К тегу "Профюмор" ввожу второй "Профужасы" (Профессиональные ужасы)