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 Invoicestabela como 'InvoiceNo', a Invoicestabela 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.
