Cada tabela deve ter uma chave primária?

340

Estou criando uma tabela de banco de dados e não tenho uma chave primária lógica atribuída a ela. Então, estou pensando em deixá-lo sem uma chave primária, mas estou me sentindo um pouco culpado por isso. Eu devo?

Cada tabela deve ter uma chave primária?

database  database-design 
— Daniel Silveira
fonte
5
Você poderia dar mais detalhes sobre a mesa? A resposta é provavelmente "sim" embora.
— 22909 Ryan Bair
7
Sim, todas as tabelas devem ter chave primária.
— Syed Tayyab Ali

Respostas:

313

Resposta curta: sim .

Resposta longa:

  • Você precisa que sua mesa seja juntável em algo
  • Se você deseja que sua tabela seja agrupada em cluster, é necessário algum tipo de chave primária.
  • Se o design da sua tabela não precisar de uma chave primária, repense o design: provavelmente você está perdendo alguma coisa. Por que manter registros idênticos?

No MySQL, o mecanismo de armazenamento InnoDB sempre cria uma chave primária se você não a especificar explicitamente, criando assim uma coluna extra à qual você não tem acesso.

Observe que uma chave primária pode ser composta.

Se você tiver uma tabela de links muitos-para-muitos, crie a chave primária em todos os campos envolvidos no link. Assim, você garante que não possui dois ou mais registros descrevendo um link.

Além dos problemas de consistência lógica, a maioria dos mecanismos RDBMS se beneficiará da inclusão desses campos em um índice exclusivo.

E como qualquer chave primária envolve a criação de um índice exclusivo, você deve declará-lo e obter consistência e desempenho lógicos.

Veja este artigo no meu blog para saber por que você sempre deve criar um índice exclusivo de dados exclusivos:

PS Existem alguns casos muito, muito especiais em que você não precisa de uma chave primária.

Principalmente eles incluem tabelas de log que não têm quaisquer índices por motivos de desempenho.

— Quassnoi
fonte
eles ainda têm uma chave primária, o composto
— kristof
2
@annakata: eles devem ter uma chave primária composta
— #
11
"E como qualquer CHAVE PRIMÁRIA envolve a criação de um índice ÚNICO" não é verdade para a Oracle. Pode-se usar um índice não exclusivo para impor uma chave primária. De fato, às vezes é NECESSÁRIO que restrições exclusivas e PK usem índices não exclusivos.
— 31713 Stephanie Página
3
Apenas um comentário sobre a pergunta retórica "Por que manter registros idênticos?". Observe que apenas adicionar uma PK não garantirá que não haja duplicação. Frequentemente, a PK não é visível para o usuário, portanto, o importante é nos campos visíveis, que podem conter dados duplicados. Dependendo do seu design, isso pode ser desejável ou não.
— Rossco
11
As chaves não têm nada a ver com a capacidade de associação. E o argumento de armazenamento em cluster depende de qual DBMS você usa e combina considerações lógicas e físicas.
— Jon Heggland
36

Sempre é melhor ter uma chave primária. Dessa forma, ele atende à primeira forma normal e permite continuar no caminho de normalização do banco de dados .

Conforme declarado por outros, existem alguns motivos para não ter uma chave primária, mas a maioria não será prejudicada se houver uma chave primária.

— Michael Wheeler
fonte
5
@PaulSuart Os dados nem sempre precisam estar em suas formas normais. De fato, quando os dados ficam grandes, eles não devem ser mantidos em sua forma normal, caso contrário, o acesso aos dados seria terrivelmente lento para consultas que fazem junções de tabelas etc. imenso.
— Pacerier
13

Sempre que eu criei uma tabela sem uma chave primária, pensando que não precisaria de uma, acabei voltando e adicionando uma. Agora, crio até minhas tabelas de junção com um campo de identidade gerado automaticamente que eu uso como chave primária.

— tvanfosson
fonte
12
Uma tabela de junção É uma chave primária - uma composta, composta pelas PKs dos dois registros que estão sendo unidos. Por exemplo, CREATE TABLE PersonOrder (PersonId int, OrderId int, PRIMARY KEY (PersonId, OrderId)).
— Keith Williams #
3
Sim, mas e se a tabela de links também tiver um terceiro atributo, digamos "OrderDate". Você adicionaria isso à chave composta também? IMHO não - porque é mais redutível e não serve o característico não redutível que uma chave primária deve ter.
— SteveK
13

Exceto em alguns casos muito raros (possivelmente uma tabela de relacionamento muitos-para-muitos ou uma tabela que você usa temporariamente para carregar grandes quantidades de dados), eu diria o seguinte:

Se não tiver uma chave primária, não será uma tabela!

Marc

— marc_s
fonte
9
A rigor, essa frase está errada. As tabelas podem ser "Exibir tabelas" criadas pelo seu idioma de consulta. Um RDBMS é composto por relações e não tabelas. Essa frase deve dizer: "Se não possui uma chave primária, não é uma relação!".
— SteveK
Ou talvez, "se não houver chaves candidatas, não será uma tabela relacional". Mas veja os casos muito raros em que não há problema em ter uma tabela que não representa uma relação.
— Walter Mitty
Por que uma tabela muitos-para-muitos não teria uma chave primária? Você pode criar uma chave primária separada e, em seguida, criar um índice exclusivo para o substituto de chaves estrangeiras. Eu acho que é melhor ter uma chave primária em todas as tabelas. Mesmo em uma tabela de carregamento em massa, você pode identificar separadamente uma chave primária que não inclui os dados importados, pois pode ajudar a identificar registros duplicados em um processo ETL. Parece-me que todas as tabelas ainda devem ter uma chave primária, mesmo que seja um pouco mais de armazenamento. Uma tabela criada por uma visualização é um subconjunto de uma tabela e não uma tabela em si.
— John Ernest
11
Em uma tabela de relacionamento muitos para muitos, você pode criar uma chave primária composta consistindo em ambos os IDs para os relacionamentos.
— 21418 Jaap
8

Você precisará associar esta tabela a outras tabelas? Você precisa de uma maneira de identificar exclusivamente um registro? Se a resposta for sim, você precisa de uma chave primária. Suponha que seus dados sejam algo como uma tabela de clientes com os nomes das pessoas que são clientes. Pode não haver uma chave natural porque você precisa dos endereços, e-mails, números de telefone etc. para determinar se Sally Smith é diferente da Sally Smith e você armazenará essas informações em tabelas relacionadas, pois a pessoa pode ter vários telefones, endereços , e-mails, etc. Suponha que Sally Smith se case com John Jones e se torne Sally Jones. Se você não tem uma chave artificial na mesa, quando atualiza o nome, você acabou de alterar 7 Sally Smiths para Sally Jones, mesmo que apenas uma delas se case e mude o nome dela.

Você diz que não possui chave natural e, portanto, também não possui nenhuma combinação de campo para tornar único, o que torna a chave artificial crítica.

Descobri a qualquer momento que não tenho uma chave natural, uma chave artificial é uma necessidade absoluta para manter a integridade dos dados. Se você possui uma chave natural, pode usá-la como o campo-chave. Mas pessoalmente, a menos que a chave natural seja um campo, ainda prefiro uma chave artificial e um índice exclusivo na chave natural. Você se arrependerá mais tarde se não colocar um.

— HLGEM
fonte
7

Basta adicioná-lo, você se arrependerá mais tarde quando não o fizer (selecionar, excluir, vincular etc.)

— raphaëλ
fonte
6

É uma boa prática ter um PK em todas as mesas, mas não é DEVE. Provavelmente você precisará de um índice exclusivo e / ou de um cluster (que é PK ou não), dependendo da sua necessidade.

Confira as seções Chaves Primárias e Índices em Cluster nos Manuais Online (para SQL Server)

"As restrições PRIMARY KEY identificam a coluna ou o conjunto de colunas que possuem valores que identificam exclusivamente uma linha em uma tabela. Não há duas linhas em uma tabela que tenham o mesmo valor de chave primária. Você não pode inserir NULL para nenhuma coluna em uma chave primária. recomendamos usar uma coluna pequena e inteira como chave primária. Cada tabela deve ter uma chave primária. Uma coluna ou combinação de colunas que se qualificam como um valor de chave primária é chamada de chave candidata " .

Mas verifique isso também: http://www.aisintl.com/case/primary_and_foreign_key.html

— endo64
fonte
11
— endo64
4
essa página é bastante estúpida. Primeiro, é necessária uma chave primária por razões de desempenho. Ao ler sua página, eu aprendo que adicionar um ID a uma tabela de livros é inútil porque o texto do livro é único; obviamente, o cara nunca trabalhou com bancos de dados, mas também tem problemas para entender o que critica. Página escrita que 1) um valor PK faz referência a uma linha 2) você pode juntar 2 tabelas por qualquer conjunto de colunas. Não há contradição. É incrível que um autor de artigo acadêmico não entenda o básico da teoria relacional.
— Federico Razzoli 11/11
11
"Primeiro, é necessária uma chave primária por razões de desempenho" isto está incorreto, o PK não afeta diretamente o desempenho. Não ter um PK pode causar muitos problemas (identificar uma linha, ingressar etc.), mas o desempenho não é um deles. Quando você cria uma PK em uma tabela, o SQL Server cria um índice em cluster exclusivo, esse índice afeta o desempenho e não a própria PK. Como um exemplo real, minha tabela possui um índice clusterizado na coluna de data e uma PK em um campo GUID, porque minhas linhas devem ser ordenadas fisicamente sobre a coluna de data da tabela, pois todas as consultas têm um intervalo de datas (no meu caso).
— Endo64 27/10/16
Esse índice clusterizado é uma amostra da chave primária, criada pelo SQL Server e vários outros DBMSs. Tem certeza de que é uma boa ideia usá-lo? Por exemplo, no MySQL, não é por várias razões não documentadas.
— Federico Razzoli
11
Lembre-se de que o GUID não é um tipo ideal para PKs, no InnoDB. Todos os índices contêm uma referência ao PK, portanto, quanto maior o PK, maiores serão todos os outros índices.
— Federico Razzoli 28/03
6

Não concorde com a resposta sugerida. A resposta curta é: NÃO .

O objetivo da chave primária é identificar exclusivamente uma linha na tabela para formar um relacionamento com outra tabela. Tradicionalmente, um valor inteiro auto-incrementado é usado para essa finalidade, mas há variações para isso.

No entanto, existem casos, por exemplo, registro de dados de séries temporais, em que a existência de uma chave desse tipo simplesmente não é necessária e apenas ocupa memória. Tornar uma linha única é simplesmente ... não necessária!

Um pequeno exemplo: Tabela A: LogData

Columns:  DateAndTime, UserId, AttribA, AttribB, AttribC etc...

Nenhuma chave primária é necessária.

Tabela B: Usuário

Columns: Id, FirstName, LastName etc.

Chave Primária (Id) necessária para ser usada como uma "chave estrangeira" na tabela LogData.

— Theodore Zographos
fonte
3

Eu sei que, para usar certos recursos do gridview no .NET, você precisa de uma chave primária para que o gridview saiba qual linha precisa ser atualizada / excluída. A prática geral deve ser ter uma chave primária ou um cluster de chaves primárias. Eu pessoalmente prefiro o primeiro.

— Tacoman667
fonte
3

Para torná-lo à prova do futuro, você realmente deveria. Se você deseja replicá-lo, precisará de um. Se você quiser se juntar a outra mesa, sua vida (e a dos pobres tolos que precisam mantê-la no próximo ano) será muito mais fácil.

— StewNoble
fonte
Ainda não estou convencido de que isso seja necessário, mas "faça-o porque, caso contrário, alguém terá que lidar com as consequências mais tarde" é suficiente para me fazer errar ao fazê-lo. Eu sempre pode apenas deixar cair a coluna mais tarde, se parece valer a pena tentar encolhê-lo para baixo ...
— ArtOfWarfare
2

Eu sempre tenho uma chave primária, mesmo que no começo ainda não tenha um objetivo em mente. Houve algumas vezes em que eu finalmente preciso de um PK em uma tabela que não tenha um e é sempre mais difícil colocá-lo mais tarde. Eu acho que há mais vantagens em incluir sempre uma.

— rvarcher
fonte
2

Estou no papel de manter o aplicativo criado pela equipe de desenvolvimento offshore. Agora, estou tendo todos os tipos de problemas no aplicativo porque o esquema original do banco de dados não contém PRIMARY KEYS em algumas tabelas. Portanto, não deixe que outras pessoas sofram por causa de seu projeto inadequado. É sempre bom ter chaves primárias nas tabelas.

— Shiva
fonte
1

Em suma, não. No entanto, você precisa ter em mente que certas operações de CRUD de acesso do cliente exigem isso. Para provas futuras, costumo utilizar sempre chaves primárias.

— Rich.Carpenter
fonte
1

Se você estiver usando o Hibernate, não será possível criar uma Entidade sem uma chave primária. Esses problemas podem criar problemas se você estiver trabalhando com um banco de dados existente criado com scripts sql / ddl simples e nenhuma chave primária foi adicionada

— Schildmeijer
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.