Acabei de me deparar com um banco de dados um pouco antigo (e frontend) e tem uma maneira engraçada de lidar com o aspecto de ids únicos.
Eu tenho uma tabela com uma única coluna e linha armazenando um Integer (atualmente 31448). Este número é usado em uma Invoices
tabela como 'InvoiceNo', a Invoices
tabela também possui um id de auto-inc único (atualmente 2847)
Parece um pouco com isso:
CREATE TABLE InvoiceNumber(
LatestId [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE Invoices(
InvoiceId [int] IDENTITY(1,1) NOT NULL,
InvoiceNo [int] NOT NULL,
Amount [decimal](18, 2) NULL
) ON [PRIMARY]
GO
Nenhum relacionamento real entre as duas tabelas além do InvoiceNo, que não é realmente um relacionamento obrigatório.
O frontend então, quando o usuário adiciona uma nova fatura, realiza o seguinte:
public static void CreateInvoice(Invoice newInvoice)
{
try
{
using (var ctx = new DataContext)
{
var lastInvoice = (from lastNumber in ctx.SingleRowTable
select lastNumber).Single;
var newInvoiceNo = lastInvoice.InvoiceNumber +1; // Int
lastInvoice.InvoiceNumber = newInvoiceNo;
newInvoice.InvoiceNo = newInvoiceNo;
ctx.Invoices.InsertOnSubmit(newInvoice);
ctx.SubmitChanges;
}
}
catch (Exception x)
{
// Sleep now in the fire
}
}
Então, basicamente, quando uma nova fatura é criada, o frontend solicita o número na tabela InvoiceNo (linha única) e adiciona um (+1) a esse número, então se torna o novo número da fatura e também o último número da fatura usada.
Outras tabelas no banco de dados (InvoiceItems) fazem referência ao InvoiceId e não ao InvoiceNo.
Suponho que a pergunta seja: Por que alguém usaria essa abordagem? é um anti-padrão ou erro de design ou existe alguma implementação real para isso?
Meu pensamento era que, por algum motivo, o número da fatura do "Mundo Real" precisava ser preservado, então eles decidiram que a execução de um 'ID exclusivo' adicional seria a melhor maneira de lidar com isso. Eu pensei que talvez os desenvolvedores não pudessem pagar um salto de mil no número da fatura. (?) Pode ser.
Eu costumava trabalhar com um programa que usava um sistema semelhante para gerar IDs exclusivos para faturas. Ele se originou em um sistema de banco de dados diferente, sem IDs de incremento automático.
Há uma diferença com o seu sistema, e é uma diferença que eu gosto muito. A
invoice
tabela tem um ID exclusivo de incremento automático - e tem um número de fatura separado, voltado para o cliente (presumo).Passei por um processo de fusão de dois bancos de dados estruturalmente idênticos. Os valores de ID de incremento automático se sobrepunham, então tivemos que redefinir um conjunto deles enquanto passávamos pelo processo de mesclagem. Nossa
invoice
tabela usou o ID exclusivo de incremento automático como o número da fatura voltada para o cliente. Portanto, perdemos funcionalmente esses números de fatura no sistema.Embora fosse potencialmente problemático ter duas faturas com o mesmo número de fatura (para o cliente), pelo menos teríamos essa opção se o valor para o cliente fosse diferente da chave primária.
A solução é uma solução 'normal' para gerar uma chave única. É usado quando o banco de dados não possui a opção de sequência ou incremento automático. Você também pode usá-lo para se tornar independente do banco de dados.