Compartilhando uma única sequência de chave primária em um banco de dados?

Aceitável? Claro. Comum? Não. Benéfico? Duvidoso.

No meu antigo emprego, herdamos um sistema onde eles tinham um gerador de sequência central (este era um sistema SQL Server muito antes de SEQUENCEser introduzido no SQL Server 2012). Não foi realmente um gargalo de desempenho e não deveria ser, a menos que você esteja gerando centenas de milhares de valores por segundo. Mas tornou todo o código muito mais complexo do que deveria ser, sem um bom motivo. A intenção do projeto era ter certeza de que, se algo no sistema recebesse um valor de ID de 12, apenas uma coisa no sistema poderia ter o ID 12. Isso parecia bastante obtuso para mim e nunca entendi. Se eu tiver um cliente com CustomerID = 12, por que isso me impede de ter um pedido com OrderID = 12?

Eu vejo a utilidade de um gerador de sequência central se você tiver vários sistemas e estiver gerando IDs para um determinado tipo de entidade (digamos, um cliente ou um pedido) desses vários sistemas. Uma sequência central pode distribuir novos valores para vários sistemas sem ser um gargalo (apenas um único ponto de falha) e sem medo de dois sistemas gerarem o mesmo ID.

A ideia tem mérito em um banco de dados muito complexo, onde as pessoas podem ingressar acidentalmente em uma tabela usando a coluna errada e obter linhas inválidas apenas porque os IDs INT são os mesmos.

Escolhemos ter GUIDs sequenciais como nossas chaves primárias para evitar algumas das armadilhas de fragmentação de índice dos GUIDs. Infelizmente eles são bem grandes.

O servidor SQL pode gerar GUIDs sequenciais por meio de um padrão invocando a função newSequentialID(), portanto, não há tabela de chaves emitidas para manter e nenhum gargalo de bloqueio.

Isso nos deu IDs exclusivos em todos os bancos de dados, em toda a nossa empresa, na verdade, pois são verdadeiramente únicos.

O preço, é claro, é o espaço e é problemático quando você tenta trazer os dados para um Data Warehouse/Cubo, onde a velocidade/tamanho é baseada no uso de chaves inteiras menores.

Estou convencido de que evitamos muitos bugs em nosso aplicativo como resultado de usá-los.

Não consigo imaginar qual pode ser a razão por trás da sequência única em todas as tabelas. Tudo o que faz é criar um gargalo ao gerar novos valores.

Não importa quão pequena seja a sobrecarga de geração de valores de chave sequencial, o gerador é um único recurso, cujo acesso deve ser sincronizado. Quanto mais solicitações ele receber, maiores serão as chances de alguns solicitantes terem que esperar sua vez de tocar. É óbvio que o gerador de sequência única compartilhado entre todas as tabelas será acessado com mais frequência por mais clientes, produzindo assim mais contenção do que qualquer um dos vários geradores. A contenção pode se tornar mais pronunciada se as regras de negócios imporem restrições aos valores gerados, como a ausência de lacunas ou ordenação estrita ou em um banco de dados em cluster.

Mesmo com o gerador de sequência mais eficiente, haverá uma carga de trabalho que causa contenção intolerável.

o objetivo da chave primária nas tabelas do banco de dados é principalmente impor a exclusividade dos dados que deveriam ser exclusivos, porque todos os fluxos de trabalho não podem ser cobertos e garantidos que não resultarão em duplicação de dados. A segunda razão é que, muitas vezes, PK também é candidato primário para índice clusterizado na tabela, portanto, também aumenta a recuperação de dados quando/onde essas colunas são usadas corretamente na consulta selecionada.

usar um número de sequência como chave primária é o mesmo que toda tabela tem coluna de identidade e apenas essa coluna está sendo usada em PrimaryKey. ter um único número de sequência no banco de dados deve ter algum uso específico, mas do ponto de vista da chave primária, não entendo o motivo. por exemplo, em um dos projetos de Datawarehouse em que trabalhei, temos uma coluna chamada LoadBatchID e do ETL para relatar 50% de toda a tabela tem essa coluna, mas em alguns lugares ela tem um significado diferente. usamos o proc exclusivo como gerador de números para garantir que não encontramos conflitos e também nos ajuda a rastrear o arquivo original de onde vieram os dados e o que acontece em cada estágio diferente do ETL.

Suponho que uma razão para fazer isso seria se todas as entidades fossem herdadas de alguma entidade pai. Digamos, por exemplo, que você queira colocar um comentário em qualquer tipo de entidade:

create table god_entity (
  id bigserial primary key
);

create table some_table (
  id bigint primary key references god_entity(id),
  ...
);

create table some_other_table (
  id bigint primary key references god_entity(id),
  ...
);

create table comment (
  id bigint primary key references god_entity(id),
  ...
);

create table entity_comment (
  entity_id bigint not null references god_entity(id),
  comment_id bigint not null references god_entity(id),

  primary key (entity_id, comment_id)
);

Normalmente isso não é feito. .

Não sei sobre as características de desempenho.