У меня есть база данных, которая не находится в производстве, поэтому основной таблицей является CustodyDetails, в этой таблице есть ID int IDENTITY(1,1) PRIMARY KEY
столбец, и я ищу способ добавления другого уникального идентификатора, на который нет ссылки ни в одной другой таблице. учетная запись содержание столбца не будет точно ключом идентификации.
Этот новый столбец идентификаторов имеет несколько конкретных деталей, и вот здесь начинается моя проблема. Формат выглядит следующим образом: XX/YY
где XX - это автоматически увеличиваемое значение, которое сбрасывает / перезапускает каждый новый год, а YY - последние 2 цифры текущего года SELECT RIGHT(YEAR(GETDATE()), 2)
.
Так, например , позволяет делать вид , один запись добавляется в день , начиная с 28/12/2015 , заканчивающимися 03/01/2016 , колонок будет выглядеть следующим образом :
ID ID2 DATE_ADDED
1 1/15 2015-12-28
2 2/15 2015-12-29
3 3/15 2015-12-30
4 4/15 2015-12-31
5 1/16 2016-01-01
6 2/16 2016-01-02
7 3/16 2016-01-03
Я подумал об использовании внешнего интерфейса для анализа составного идентификатора (ID2 в примере), чтобы получить последние 2 цифры и сравнить с последними 2 цифрами текущего года, а затем решить, стоит ли начинать новый коррелятивный анализ. Конечно, было бы здорово иметь возможность делать все это на стороне базы данных.
РЕДАКТИРОВАТЬ 1: Кстати, я также видел людей, использующих отдельные таблицы только для хранения параллельных ключей идентификации, поэтому один ключ идентификации таблицы становится вторым дополнительным ключом таблицы, это звучит немного странно, но, может быть, в таком случае такая реализация имеет место?
РЕДАКТИРОВАТЬ 2: Этот дополнительный идентификатор является ссылкой на устаревший документ, который помечает каждый файл / запись. Я думаю, что это можно назвать специальным псевдонимом для основного идентификатора.
Количество записей, которые эта база данных обрабатывает ежегодно , не превышало 100 за последние 20 лет и очень (действительно, очень высоко) маловероятно, что, конечно, если оно превысит 99, то поле сможет продолжайте с дополнительной цифрой, и интерфейс / процедура сможет перейти более 99, так что это не так, как будто это что-то меняет.
Конечно, некоторые из этих деталей я не упомянул вначале, потому что они только сузили возможности решения в соответствии с моими конкретными потребностями, попытались сохранить диапазон проблем более широким.
ID
= 5, 6 и 7, DATE_ADDED должен быть2016-01-01
и так далее?Ответы:
Вы можете использовать таблицу ключей для хранения возрастающей части вашего второго столбца идентификаторов. Это решение не опирается на какой-либо код на стороне клиента и автоматически поддерживает многолетнюю работу; когда
@DateAdded
параметр переходит в ранее неиспользованный год, он автоматически начинает использовать новый набор значений дляID2
столбца на основе этого года. Если процедура используется для вставки строк предыдущих лет, эти строки будут вставлены с «правильными» значениями для приращения. ПроцессGetNextID()
предназначен для корректной обработки возможных взаимоблокировок, передавая только вызывающей стороне ошибку, если при попытке обновленияtblIDs
таблицы возникают 5 последовательных взаимоблокировок .Создайте таблицу для хранения одной строки в год, содержащей текущее используемое значение идентификатора, а также хранимую процедуру для возврата нового значения:
Ваша таблица вместе с процедурой для вставки в нее строк:
Вставьте пример данных:
Показать обе таблицы:
Результаты:
Таблица ключей и хранимый процесс происходят из этого вопроса.
источник
(IDName, LastID)
строку, это приведет к тупику или к одной из транзакций, нарушающих PK? Если последнее, возможно, имело бы смысл дать этой транзакции еще один шанс (чтобы она в итоге получила идентификатор 2).@NewID
явно установил значение null в начале цикла: если транзакция, которая пытается вставить строку, становится жертвой взаимоблокировки, она не будет пытаться вставить строку на следующей итерации, потому@NewID
что уже будет иметь был установлен в 1 (который не равен NULL, и поэтому ветка INSERT будет опущена).tblIDs
таблицу, поскольку эта таблица обновляется с помощью одной атомарной операции; "Причудливое" обновление.@NewID = NULL
в начале цикла.