Adicionar um ID em todas as tabelas, mesmo que não seja necessário?

8

Esse projeto é bom ou ruim para adicionar, por padrão, o campo ID em todas as tabelas de um banco de dados, mesmo quando você não vê atualmente o uso desse ID (por exemplo, em uma tabela MxN)?

database-design Pierre Watelet
fonte
se você não tiver uma coluna de ID, outros campos formariam a chave primária?
Thanos Papathanasiou
I normalmente adicionar um ID se eles provavelmente são usados em outra tabela ... seria economizar espaço, embora apenas um pouco
ZFM

Respostas:

3

Em muitos casos, ter um ID artificial em todas as tabelas é muito conveniente; em alguns casos, é apenas uma dor no a **.

Geralmente, faço isso em todos os projetos em que estou trabalhando.

Vantagens:

  • Geralmente é mais fácil escrever ou gerar código de acesso quando todas as tabelas podem ser acessadas por um campo-chave chamado IDtipo Integer.

  • Às vezes, as chaves naturais são voláteis. Por exemplo, em um sistema de gerenciamento de armazém já bastante complexo, tivemos a tarefa de alterar os códigos do produto, por exemplo, o que foi o produto 001234 será conhecido como 002345 no futuro. Infelizmente, esse sistema não usou IDs artificiais, mas o código do produto como chave primária. Naturalmente, o código do produto também era uma chave estrangeira em dezenas de outras tabelas. Portanto, renumerar era realmente difícil e caro e não podia ser feito durante o horário de trabalho. A próxima versão do software usava IDs artificiais, portanto, era apenas uma simples atualização na tabela de produtos.

  • Às vezes, as chaves naturais não são exclusivas, mesmo que devam ser. Nos meus países, por alguns motivos, alguns SSN foram emitidos duas vezes.

  • Chaves concetentadas se tornam complicadas quando a estrutura de dados é complexa; Ter uma sub-sub-sub-tabela com uma chave concetenada de 4 partes é bastante trabalhoso.

Desvantagens:

  • Por sua natureza, esses IDs não têm significado fora do sistema, portanto, você precisa de muitas pesquisas para converter esses IDs em chaves naturais.

  • Obter a chave superior da referida sub-sub-sub-tabela requer uma grande junção em toda a hierarquia.

  • A fusão de dados recebidos com os registros existentes é mais difícil, pois são necessárias mais pesquisas.

user281377
fonte
2
Bullet 2: Isso foi antes ON UPDATE CASCADE?
Izkata
1
@ Izkata, eu nunca permitiria a atualização em cascata em um banco de dados no nível corporativo, pois é muito provável que cause problemas de desempenho / bloqueio / bloqueio quando um grande número de registros é alterado. Você realmente não deseja bloquear os usuários enquanto 10.000.000 de registros são atualizados. É por isso que muitas pessoas acreditam que uma chave volátil é ruim, pois causa muito trabalho no banco de dados quando muda.
HLGEM #
@HLGEM Embora eu admita não ter um banco de dados como esse para brincar, parece-me que o bloqueio no nível de linha do InnoDB ajudaria a atenuá-lo, especialmente se fossem adicionadas pausas entre a atualização de todos os registros X. Além disso, da maneira que a ammoQ a descrevia, o verdadeiro problema era que eles precisariam alterar manualmente todas as chaves estrangeiras (o mecanismo MyISAM no MySQL, por exemplo, não suporta).
Izkata
Izkata: O problema não estava emitindo 30 instruções de atualização em vez de uma. Essa parte é fácil, mesmo sem o uso de atualizações em cascata. O verdadeiro problema estava afetando muitos milhares de linhas em vez de uma, causando conflitos em todo o sistema (reconhecidamente não muito bem projetado). Eventualmente, houve um trabalho noturno para fazer isso.
user281377
1
+1 desvantagem: é mais difícil de mover dados entre diferentes ambientes (dev, em, produção, etc.)
Marco Lackovic
6

chaves sintéticas versus chaves naturais e chaves únicas versus chaves compostas são tópicos muito debatidos e que têm bons pontos positivos e negativos em ambos os lados. Eles são como abas versus espaços e colchetes em seus próprios debates de linha.

O mais importante é escolher um lado e manter a consistência em todo o banco de dados. geralmente chaves sintéticas são usadas simplesmente porque é difícil ter uma boa chave natural para todas as tabelas e é muito mais fácil ser consistente quando todas as tabelas possuem uma chave sintética.

Ryathal
fonte
4

Cada tabela deve ter um PK, um identificador exclusivo ou um ID como você está chamando. No caso de MxN, você tem PK (um composto). Portanto, não há necessidade de ter outro.

Consulte também: Uma ou duas chaves primárias na tabela muitos para muitos?

Minha preferência pessoal referente a um tópico relacionado: PKs não devem ter outro uso além de serem PKs. Portanto, eu não usaria dados aa PK, mesmo que os dados sejam "Naturalmente exclusivos" IE: SSN, Data, CEP, Ect.

Idiotas
fonte
1
Você se contradiz. As colunas da chave composta na tabela de relação têm outro uso além de ser uma PK. Eles também são chaves estrangeiras. (Além disso, eu não concordo. Se você tem alguma coisa, isso é naturalmente PK, eu simplesmente aceitaria. Se não tivesse restrições, certamente terminaria com entradas conflitantes um dia e se a restrição está lá, por que não usá-lo como chave primária).
Jan Hudec
2
Geralmente, os Pks são usados ​​como FKs em diferentes tabelas que fazem parte de ser um PK, não vejo contradição.
Idiotas
1
Entendo sua posição em relação às chaves naturais, foi assim que tive o cuidado de afirmar que essa é minha preferência pessoal.
Idiotas
3
@JanHudec: Coisas naturalmente únicas tendem a mudar naturalmente. Além disso, eu já vi muitas vezes que as chaves naturais tendem a ser não-inteiros, como cordas, o que leva a problemas de desempenho, se usados como PK>
Goran Jovic
Você também enfrenta problemas nos quais precisa lidar com erros de digitação nos PKs. Isso costumava me deixar louco.
Idiotas
0

Do ponto de vista do design, use a chave primária composta natural e não invente uma chave sintética. Tudo o que não precisa estar lá apenas torna o esquema mais complicado de entender.

Do ponto de vista do desempenho em muitos bancos de dados, é mais rápido acessar a tabela por chave primária inteira do que por qualquer outra coluna indexada. Esses bancos de dados também incluirão implicitamente essa chave sintética em qualquer tabela que não possua uma (geralmente chamada "rowid" ou "oid" ou similar), portanto, adicioná-la explicitamente não custará nada.

Para tabelas MxN (relação), não faz sentido acessá-las por chave primária; você os acessa por qualquer componente e obtém o conjunto de entidades relacionadas do outro lado. Portanto, para essas tabelas, não faz sentido adicionar chave primária sintética.

Para outras tabelas com boa chave primária composta ou não inteira, ainda não adicionaria uma sintética inicialmente, mas consideraria incluí-la durante o ajuste de desempenho para tabelas acessadas em tabelas críticas de desempenho.

Jan Hudec
fonte