У меня есть база данных, которая не находится в производстве, поэтому основной таблицей является 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
и так далее?