Eu tenho um banco de dados que não está em produção, então a tabela principal sendo CustodyDetails, esta tabela tem uma ID int IDENTITY(1,1) PRIMARY KEY
coluna e estou procurando uma maneira de adicionar outro identificador exclusivo que não seja referenciado em nenhuma outra tabela, eu pensaria levando isso em conta o conteúdo da coluna não seria exatamente uma chave de identidade.
Esta nova coluna de identidade tem alguns detalhes específicos, e é aqui que meu problema começa. O formato é o seguinte: XX/YY
onde XX é um valor incrementável automaticamente que reinicia/reinicia a cada novo ano e YY são os últimos 2 dígitos do ano atual SELECT RIGHT(YEAR(GETDATE()), 2)
.
Então, por exemplo, vamos fingir que um registro é adicionado um dia a partir de 28/12/2015 terminando em 03/01/2016 , a coluna ficaria assim:
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
Pensei em usar o frontend para analisar o ID composto (ID2 no exemplo), obter os 2 últimos dígitos e comparar com os 2 últimos dígitos do ano atual e então decidir se inicia ou não um novo correlativo. Claro que seria ótimo poder fazer tudo isso no lado do banco de dados.
EDIT 1: btw, eu também vi pessoas usando tabelas separadas apenas para armazenar chaves de identidade paralelas, então uma chave de identidade de tabela se torna uma chave secundária de segunda tabela, isso soa um pouco duvidoso, mas talvez seja esse o caso de tal implementação?
EDIT 2: Este ID extra é uma referência de documento legado que rotula cada arquivo/registro. Acho que alguém poderia pensar nisso como um alias especial para o ID principal.
O número de registros que este banco de dados lida anualmente não passou dos 100 nos últimos 20 anos e é altamente (realmente, extremamente altamente) improvável que fosse, é claro, se ultrapassar 99, o campo será capaz de continue com o dígito extra e o frontend/procedimento poderá ultrapassar 99, então não é como se isso mudasse as coisas.
É claro que alguns desses detalhes não mencionei no início porque apenas restringiriam as possibilidades de solução para atender à minha necessidade específica, tentei manter o leque de problemas mais amplo.
Você pode usar uma tabela de chaves para armazenar a parte incrementada de sua segunda coluna de ID. Essa solução não depende de nenhum código do lado do cliente e é automaticamente ciente de vários anos; quando o
@DateAdded
parâmetro passar em um ano não utilizado anteriormente, ele começará automaticamente a usar um novo conjunto de valores para aID2
coluna, com base naquele ano. Se o proc for consequentemente usado para inserir linhas de anos anteriores, essas linhas serão inseridas com valores "corretos" para o incremento. OGetNextID()
proc é voltado para lidar com possíveis impasses normalmente, apenas passando um erro para o chamador se ocorrerem 5 impasses sequenciais ao tentar atualizar atblIDs
tabela.Crie uma tabela para armazenar uma linha por ano contendo o valor de ID usado atualmente, juntamente com um procedimento armazenado para retornar o novo valor a ser usado:
Sua tabela, juntamente com um procedimento para inserir linhas nela:
Insira alguns dados de amostra:
Mostre as duas tabelas:
Resultados:
A tabela de chaves e o procedimento armazenado vêm desta questão.