Chave Composta, Recurso ou Problema?

Bem Vindo! Nesse PAPO DEV vamos falar de um assunto que está relacionado a projeto de banco de dados. Quero deixar claro que não sou DBA, nem pretendo ensinar nada sobre isso. Vamos apenas colocar em questão um assunto que pode interessar a muitos desenvolvedores. Tenho minha opinião formada sobre a questão. Mais claro ninguém é dono da verdade, e podem existir pontos que eu desconheço.

Atualmente desenvolvo sistemas para automação comercial e contábil, e por essa razão já tive contato com banco de dados de vários fabricantes (a maioria de pequeno porte).  Percebi ao longo do tempo que existem muitos projetos de banco de dados que são bem confusos, as vezes não chegam nem perto de ser normalizados, não apresentam consistência, e o mais impressionante, nem sequer utilizam PK e FK para relacionar tabelas, (pode acreditar, muitas coisas bizarras). Mais o que vamos focar aqui é um caso que vejo frequentemente, a utilização de chave composta.

Não afirmo que essa prática é errada ou que quem usa  não sabe o que está fazendo, mais até agora não encontrei um motivo aceitável para utilizar tal recurso.  Vou explicar agora por que tenho essa opinião.

Imagine que tenho uma tabela de nota fiscal e outra de item da nota fiscal, tenho os campos numero da nota, série, fornecedor, essa combinação não poderá se repetir, o que acontece muito é ver essas combinações serem definidas como chave primária composta. Isso funciona? Claro que funciona, porém acredito que não seja a melhor saída para resolver o problema. Um conceito que sempre sigo é “não misturar regra de negócio com tecnologia”, e principalmente ao banco de dados. Fazendo com que esses campos sejam chave primária estou correndo um risco muito grande. Pensa comigo, regra de negócio muda, isso é um fato, se algum dia essa regra de chave mudar compromete a integridade da informação que já foi armazenada. Então minha dica é, sempre use um campo chave auto incremental simples, dessa forma o relacionamento entre as tabelas do banco de dados vai ser responsabilidade única do SGBD. Para resolver o problema da não repetição de registros é possível utilizar chave única que é um recurso do SGBD, que pode impactar menos quando há mudança na regra de negócio, ou até mesmo na sua camada de negócio do projeto.

Bem, é isso. Você pode deixar sua opinião, é interessante que o assunto seja discutido para que o conhecimento seja acrescentado.

Até a próxima!

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s