Você vai se arrepender de usar chaves naturais

• Chaves naturais são usadas em bancos de dados para garantir unicidade
• Chaves naturais se baseiam em dados reais, como nome, cidade, ano etc.
• Por exemplo, em um banco de dados dos 50 melhores restaurantes do mundo, restaurantName, cityName e year poderiam ser usados como chave natural
• No entanto, chaves naturais podem não garantir unicidade. Por exemplo, pode haver restaurantes com o mesmo nome em várias cidades

Identidade

• Além de garantir unicidade, chaves naturais também precisam garantir identidade
• Por exemplo, o número do chassi de um carro ou um número de identificação pessoal (número CPR) poderiam ser usados como chave natural
• No entanto, a mesma pessoa pode ter vários números de identificação. Por exemplo, na Dinamarca, uma pessoa trans pode receber um novo número CPR

Erros de registro

• Chaves naturais são vulneráveis a erros de registro
• Podem ocorrer erros de entrada de dados, erros de digitação do usuário e erros de conversão de dados
• O sistema precisa ser capaz de corrigir esses erros. Portanto, não é adequado usar chaves externas como chaves do banco de dados

Conclusão

• Usar chaves naturais no projeto do banco de dados não é uma boa ideia
• Erros de dados podem ocorrer, e deve ser possível corrigir esses erros
• Portanto, é recomendável sempre usar chaves artificiais nas tabelas do banco de dados

Opinião do GN⁺

• Problemas das chaves naturais: chaves naturais podem não garantir unicidade nem identidade e são vulneráveis a erros de entrada de dados.
• Vantagens das chaves artificiais: chaves artificiais garantem unicidade e identidade, além de facilitar a correção de erros de dados.
• Pontos a considerar ao usar ORM: ao usar bibliotecas ORM, é mais fácil trabalhar com chaves artificiais. Como o ORM determina parte da estrutura do banco de dados, usar chaves artificiais tende a ser mais eficiente.
• Produtos com funcionalidade semelhante: outras ferramentas de modelagem de banco de dados e bibliotecas ORM também recomendam o uso de chaves artificiais. Exemplos incluem Hibernate e Entity Framework.
• Pontos a considerar na adoção da tecnologia: ao adotar um novo projeto de banco de dados, é melhor considerar as desvantagens das chaves naturais e optar por chaves artificiais. Chaves artificiais ajudam a garantir a integridade dos dados e facilitam a correção de erros.

[GN⁺]

Comentários no Hacker News

• IDs únicos, curtos e legíveis por humanos: preferência por IDs como cus_MJA953cFzEuO1z, usados pela Stripe. Também há uma forma de gerá-los em JavaScript/TypeScript.
• Números de identificação pessoal: comparação entre o número CPR da Dinamarca e o SSN dos EUA. O SSN não é único, pode mudar e pode ser emitido mesmo para quem não é cidadão dos EUA. Recomenda-se não usá-lo como chave de banco de dados.
• Aliases e logs de auditoria: ao usar chaves naturais como o número CPR dinamarquês, é necessária uma tabela separada para registrar alterações. URLs também podem ser usadas como chave natural, mas, se mudarem, é preciso criar uma tabela de redirecionamento.
• Limites das chaves naturais: se um identificador único mudar, é preciso rastrear todas as informações relacionadas. Adicionar uma chave artificial aumenta ainda mais a quantidade de informação a ser rastreada. A modelagem de dados deve refletir o mundo real.
• Chaves naturais e privacidade: se uma chave natural contiver informações pessoais, isso pode se propagar para outras tabelas por meio de chaves estrangeiras.
• Exemplo de gamertag: exemplo de uso da gamertag da PlayStation Network como chave natural. Se a gamertag não mudar, ela pode servir como identificador único.
• Exemplo da área médica: problemas podem surgir quando um funcionário do cadastro digita o número de saúde pessoal (PHN) errado. Com uma chave artificial, a correção pode ser feita depois.
• Falta de controle sobre chaves naturais: nomes, endereços, números oficiais de registro etc. não estão sob seu controle, então não são confiáveis. É melhor usar um sistema de chaves únicas.
• Uso de chaves artificiais: usar um campo de ID único em todas as tabelas facilita a resolução de problemas. Como os dados e os relacionamentos mudam com frequência, é difícil confiar em chaves naturais.
• Mutabilidade e IDs únicos: a possibilidade de mudança exige um identificador comum ao longo do tempo. O banco de dados deve incluir chaves substitutas explícitas no esquema.

[jsonobject]

Eu também recomendo usar TSID, que já está preparado para ambientes distribuídos, incluindo suporte a regiões globais, em vez de chaves artificiais. Eu uso TSID como PK no MySQL e no DynamoDB.

https://jsonobject.hashnode.dev/using-tsid-as-database-pk