O que há de especial na chave primária?
Qual é o objetivo de uma tabela em um esquema? Qual é o propósito de uma chave de uma tabela? O que há de especial na chave primária? As discussões em torno das chaves primárias parecem não entender o ponto em que a chave primária faz parte de uma tabela e essa tabela faz parte de um esquema. O que é melhor para a tabela e os relacionamentos da tabela deve orientar a chave usada.
As tabelas (e os relacionamentos das tabelas) contêm fatos sobre as informações que você deseja registrar. Esses fatos devem ser independentes, significativos, facilmente compreendidos e não contraditórios. Da perspectiva do design, outras tabelas adicionadas ou removidas de um esquema não devem impactar a tabela em questão. Deve haver um objetivo de armazenar os dados relacionados apenas às informações em si. Entender o que é armazenado em uma tabela não deve exigir a realização de um projeto de pesquisa científica. Nenhum fato armazenado para a mesma finalidade deve ser armazenado mais de uma vez. As chaves são uma parte ou parte das informações que estão sendo registradas, únicas, e a chave primária é a chave especialmente designada que deve ser o ponto de acesso principal da tabela (ou seja, deve ser escolhida para consistência e uso dos dados, não apenas inserir desempenho).
- LADO Lateral: Infelizmente, o efeito colateral da maioria dos bancos de dados sendo projetados e desenvolvidos por programadores de aplicativos (o que eu sou algumas vezes) é que o melhor para o aplicativo ou a estrutura do aplicativo geralmente direciona a opção de chave primária para as tabelas. Isso leva a chaves inteiras e GUID (como essas são simples de usar para estruturas de aplicativos) e a designs de tabelas monolíticas (pois reduzem o número de objetos da estrutura de aplicativos necessários para representar os dados na memória). Essas decisões de design de banco de dados orientadas a aplicativos levam a problemas significativos de consistência de dados quando usados em escala. As estruturas de aplicativos projetadas dessa maneira naturalmente levam a projetos de tabela por vez. "Registros parciais" são criados em tabelas e dados preenchidos ao longo do tempo. A interação de várias tabelas é evitada ou quando usada causa dados inconsistentes quando o aplicativo funciona incorretamente. Esses designs levam a dados que não têm sentido (ou são difíceis de entender), espalham-se por tabelas (é necessário examinar outras tabelas para entender a tabela atual) e duplicar os dados.
Dizia-se que as chaves primárias deveriam ser tão pequenas quanto necessárias. Eu diria que as chaves devem ter apenas o tamanho necessário. A adição aleatória de campos sem sentido a uma tabela deve ser evitada. É ainda pior criar uma chave de um campo sem sentido adicionado aleatoriamente, especialmente quando ela destrói a dependência de junção de outra tabela na chave não primária. Isso é razoável apenas se não houver boas chaves candidatas na tabela, mas essa ocorrência certamente é um sinal de um design de esquema ruim se usado para todas as tabelas.
Também foi dito que as chaves primárias nunca deveriam mudar, pois a atualização de uma chave primária sempre deveria estar fora de questão. Mas atualização é o mesmo que excluir, seguido de inserção. Por essa lógica, você nunca deve excluir um registro de uma tabela com uma chave e adicionar outro registro com uma segunda chave. Adicionar a chave primária substituta não remove o fato de que a outra chave na tabela existe. A atualização de uma chave não primária de uma tabela pode destruir o significado dos dados se outras tabelas dependem desse significado por meio de uma chave substituta (por exemplo, uma tabela de status com uma chave substituta cuja descrição do status foi alterada de 'Processado' para 'Cancelado definitivamente corromperia os dados). O que sempre deve estar fora de questão é destruir o significado dos dados.
Dito isso, sou grato pelos muitos bancos de dados mal projetados que existem hoje nas empresas (gigantes sem sentido-substitutos-com-dados-corrompidos-1NF), porque isso significa que há uma quantidade infinita de trabalho para pessoas que entendem o design adequado do banco de dados . Mas, no lado triste, às vezes me faz sentir como Sísifo, mas aposto que ele tinha um total de 401k (antes do acidente). Fique longe de blogs e sites para perguntas importantes sobre o design do banco de dados. Se você estiver projetando bancos de dados, procure Data CJ. Você também pode fazer referência ao Celko para SQL Server, mas apenas se segurar o nariz primeiro. No lado do Oracle, consulte Tom Kyte.