- O que são chaves?
- Chaves simples
- Chaves concatenadas ou compostas
- Chaves Primárias
- Numeração e incremento automático
- Uma tabela pode conter várias chaves primárias?
Enquanto muitos desenvolvedores e administradores de banco de dados podem trabalhar com
primary keys todos os dias, é um tópico fascinante perguntar a si mesmo:"O que exatamente é uma primary key e pode (ou deve) uma tabela de banco de dados conter várias primary keys simultaneamente?" Abaixo, examinaremos essas questões com mais detalhes e tentaremos chegar a um consenso razoável e geralmente acordado dentro da comunidade de desenvolvimento.
O que são chaves?
Para entender o que é uma
primary key está em uma tabela de banco de dados, devemos primeiro entender um pouco sobre non-primary keys . Uma key em uma tabela é simplesmente um atributo que é usado para identificar e acessar essas informações. Uma tabela pode e muitas vezes terá várias chaves, como na tabela Users ambos email e username podem ser considerados chaves. Dependendo do desenvolvedor ou administrador com quem você está falando, você pode ouvir sobre uma variedade de tipos de chave e suas definições, portanto, abordaremos apenas alguns exemplos diferentes abaixo e uma definição básica de cada um.
Chaves simples
Uma
simple key é apenas uma chave usando apenas um único atributo na tabela. A menos que imponhamos mais restrições à chave ou à tabela, então o username atributo no exemplo acima é uma simple key . Chaves concatenadas ou compostas
Um passo além das
simple keys são concatenated ou compound chaves. Como o nome indica, uma concatenated key é uma junção de várias single keys . Por exemplo, o sistema pode combinar automaticamente o last_name e year_of_birth simple keys em uma concatenated key , assim:smith1980 . Chaves primárias
Uma
[primary key](https://en.wikipedia.org/wiki/Unique_key) é uma chave que foi escolhida para ser a principal (ou primária ) atributo representativo para essa linha de dados. A primary key é único e esse atributo é então usado em todo o banco de dados e é acessado e passado para outras tabelas como o atributo representativo dos dados em questão. Na prática, a
primary key atributo também é marcado como NOT NULL na maioria dos bancos de dados, o que significa que o atributo deve sempre conter um valor para que o registro seja inserido na tabela. Como exemplo, o
email ou username simple keys poderia ser atribuída a designação da primary key , mas normalmente é uma prática recomendada definir a primary key a um atributo que não é (ou não poderia) ser alterado pela lógica de negócios ou mesmo pelo indivíduo. Por exemplo, imagine um User recebe um novo endereço de e-mail, o que faz com que todas as primary key anteriores associações feitas com o endereço de e-mail antigo se tornem inválidas ao usar o novo endereço de e-mail. Por esse motivo (entre outros), a maioria das
primary keys use um número ou uma string exclusiva, como um [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) . Numeração e incremento automático
Também vale a pena notar brevemente que muitos sistemas de banco de dados são configurados de forma que cada tabela tenha uma
primary key que é numérico e também é incrementado automaticamente. Isso significa simplesmente que o próprio mecanismo de banco de dados atribui automaticamente a cada novo registro nessa tabela uma primary key exclusiva valor que é incrementalmente maior do que todos os valores anteriores. No entanto, a maioria dos desenvolvedores concorda que essa prática está desatualizada e expõe falhas de segurança desnecessárias para o sistema quando usado para algumas tabelas que representam determinados dados. Por exemplo, imagine todos os
User registros são atribuídos a uma primary key auto-incrementada valor, conhecido como id atributo. Se uma pessoa mal-intencionada descobrir que o id atributo de um determinado usuário (por exemplo, John Smith) é o valor 1500 , isso já expõe um pouco de informação. Primeiro, indica que provavelmente há pelo menos 1.499 outros usuários no sistema, ou houve em algum momento. Isso também significa que, se a página de usuário de John Smith puder ser acessada por meio de uma URL ou chamada de API que contenha esse id valor de 1500 , há uma boa chance de simplesmente alterar o valor para outro número, como 1499 ou 1501 , irá expor a página de outro usuário que pode não querer que sua página seja acessada por este visitante. Dessa forma, os registros podem ser consultados simplesmente supondo o id valores em escala de massa. Obviamente, esses são exemplos muito simples, mas por esses motivos a maioria dos bancos de dados modernos usará uma
primary key aleatória e exclusiva valor de atributo como um UUID ao trabalhar com dados confidenciais. Uma tabela pode conter várias chaves primárias?
A resposta curta é não , uma tabela não pode conter várias
primary keys , pois isso vai contra os princípios fundamentais do design de banco de dados relacional (consulte:[database normalisation](https://en.wikipedia.org/wiki/Database_normalisation) e [Third normal form](https://en.wikipedia.org/wiki/Third_normal_form) ). É é possível para uma tabela ter várias
candidate keys , que efetivamente se comportam de forma semelhante a uma primary key em que uma candidate key é único, NOT NULL , e é uma representação singular desse registro de tabela. No entanto, quando se trata de selecionar qual um atributo será atribuído como a
primary key para a tabela, a escolha vem da lista de todas as possíveis candidate keys (daí o nome, eles são candidatos a se tornar uma primary key ). Em última análise, apenas uma candidate key é selecionado como o melhor atributo representativo para esse registro, para ser usado nesta tabela como a primary key e referenciado em outro lugar no banco de dados por outras tabelas por meio de suas respectivas foreign keys . 
