ti-enxame.com

Uma chave primária deve ser imutável?

Uma pergunta recente sobre stackoverflow provocou uma discussão sobre a imutabilidade de chaves primárias. Eu pensava que era um tipo de regra que as chaves primárias deveriam ser imutáveis. Se houver uma chance de algum dia uma chave primária ser atualizada, achei que você deveria usar uma chave substituta. No entanto, ele não está no padrão SQL e alguns recursos de "atualização em cascata" do RDBMS permitem que uma chave primária seja alterada.

Então, minha pergunta é: ainda é uma prática ruim ter uma chave primária que possa mudar? Quais são os contras, se houver, de ter uma chave primária mutável?

27
Vincent Malgrat

Você apenas precisa a chave primária para ser imutável se estiver vinculada a uma chave estrangeira ou se for usada como um identificador fora do banco de dados (por exemplo, em um URL que aponta para uma página do item).

Por outro lado, você apenas precisa para ter uma chave mutável se ela tiver alguma informação que possa mudar. Eu sempre uso uma chave substituta se o registro não tiver um identificador simples e imutável que possa ser usado como chave.

25
Guffa

Uma chave primária deve deve ser composta de quaisquer tuplas necessárias para determinar a exclusividade. Se os dados podem mudar ou não, é irrelevante. Somente a singularidade do registro é importante. Esse é o design conceitual do banco de dados.

Quando passamos ao domínio da implementação, a coisa mais segura a fazer é simplesmente usar uma chave substituta.

15
Chris Holmes

Sim, na minha opinião, uma chave primária deve ser imutável.

Mesmo se houver chaves candidatas óbvias, eu sempre uso uma chave substituta. Nas poucas ocasiões em que não fiz isso, quase sempre me arrependi. E não importa o quão imutável você pense que a chave é, você não pode se proteger contra erros de entrada de dados - dizendo aos usuários que eles não podem editar essa parte da informação porque é uma chave primária que não lava muito.

15
richeym

Os mecanismos de armazenamento em cache entre o banco de dados e o usuário perderão a eficácia se as chaves primárias mudarem.

2
spoulson

Por que não? Porque você deseja eliminar uma coluna?

Só porque os requisitos exigem que três colunas sejam únicas, não significa que ela tenha que ser a chave primária. Você pode pensar que essa regra vai durar para sempre (lembre-se durante a reunião em que o gerente do departamento de alfinetadas jurou que nunca mudaria? Você sabe, a que acabou de ser demitida.), Mas não vai.

Eu não sou pago por todas as atualizações em cascata que eu implemento e um bônus se eu mesmo codificá-las.

O computador não requer nenhum significado para uma chave; IMHO, as chaves são para computadores, deixe as pessoas estragar o resto dos dados.

2
JeffO

Não é uma prática ruim ter uma chave cujos valores possam mudar.

As propriedades de uma boa chave incluem estabilidade. A imutabilidade é ideal, mas não é um pré-requisito. Introduzir uma chave artificial em prol da imutabilidade é uma má prática.

Veja o exemplo de Número internacional padrão de livros (ISBN) . É muito estável, mas não imutável: em algum momento os editores de livros cometem erros e - horror! - números duplicados de ISBN podem ocorrer. Isso significa que o ISBN não deve ser aceito como uma chave candidata em um banco de dados computadorizado? Claro que não. Uma das vantagens do ISBN é que ele possui uma fonte confiável que resolverá problemas para todos os usuários globalmente.

Existem outras conveniências de uma boa chave que o ISBN possui que falta uma chave inteira com incremento automático sem sentido, por exemplo familiaridade (todo mundo no ramo de livros conhece ou conhece o ISBN), verificável (o ISBN é impresso em todos os livros modernos), pode ser validado com referência ao DBMS (o ISBN é de largura fixa e inclui uma soma de verificação), etc.

2
onedaywhen

Sim, uma chave primária deve ser imutável, além de ser nula e exclusiva. No entanto, ainda tenho que encontrar um banco de dados que imponha a imutabilidade das chaves primárias, para que você provavelmente possa prosseguir e alterar seus valores, se realmente quiser.

1

Tudo o que pode ser imutável deveria ser. Isso ajuda a garantir a correção e ajuda quando você deseja tornar seu aplicativo multithread.

1
dash-tom-bang

Como alguns comentários já disseram, uma solução é usar uma nova chave primária

Por exemplo (seguindo o exemplo de @onedaywhen), digamos que exista a tabela Livros que armazena uma lista de livros e nós "usamos" para determinar o ISBN como a chave primária. No entanto, alguns autores cometeram o erro de digitar um ISBN errado e, portanto, solicitaram a alteração do ISBN, envolvendo as próximas tarefas:

  • crie um novo registro na tabela Livros
  • aponte todas as referências do ISBN antigo para o novo ISBN. (*)
  • E, finalmente, exclua o registro antigo da tabela Livros.

(*) isso pode ser trivial para encontrar todas as referências para um modelo de banco de dados que usa chaves estrangeiras, mas alguns modelos não possuem.

Table Books
ISBN  is the primary key
NAME is a simple field.
etc.

Nós mudamos isso como

Table Books
InternalBookId as the primary key
ISBN as a simple field or an indexed field.
NAME is a simple field.
etc.

Onde o novo InternalBookId poderia até ser um valor autonumérico.

Os contras sobre isso:

  • ele adiciona um novo campo que usa mais espaço/recurso.

  • isso poderia exigir a reescrita de todo o modelo.

  • o novo modelo poderia ser menos auto-explicado.

O profissional

  • Permite alterar a "chave primária".
  • Permite até mesmo soltar ou refatorar a "chave primária", por exemplo, alterar Livros para ISBN-13 é tão simples que soltar a coluna mais antiga e criar uma nova

Nova tabela:

Table Books
InternalBookId as the primary key
ISBN13 is a new field.
NAME is a simple field.
etc.
0
magallanes