Profissionais TI - Pra quem respira informação

Saudações, leitores, tudo certo?

Só uma pergunta: no seu sistema, o usuário pesquisa pela chave primária para encontrar um registro, como, por exemplo, pelo código do cliente?

Se a resposta for positiva, convido-o para ler este artigo sobre chaves primárias e chaves de negócio. Talvez você irá repensar os seus Selects, haha!

Sabemos que atualmente é comum trabalhar com chaves primárias expostas para o usuário. Em uma tabela de produtos, o código, que é a chave primária, é exibido na tela de consulta como identificador do registro. Como efeito, usuários normalmente decoram a chave primária dos registros para agilizar o trabalho. Segue um exemplo clássico:

“João, qual é o código do produto XPTO?”
“568, José!”

Ótimo! Isso ajuda, e muito, na produtividade dos usuários.

Porém, tenho algo para revelar: esse não é o objetivo de uma chave primária. E acrescento: chaves primárias não deveriam ser exibidas para o usuário no sistema!

Como assim, André?

Se você sabe o que é uma chave primária e qual o seu objetivo, irá compreender facilmente a minha objeção. Chaves primárias são (ou deveriam ser) exclusivamente utilizadas pelo motor do banco de dados para controlar registros únicos em uma tabela. Essas chaves são utilizadas para manipular registros, como alterações e exclusões, comportarem-se como índices e principalmente para fazer ligações (joins) com outras tabelas.

Chaves primárias não são manipuláveis pelo usuário. Geralmente são campos imutáveis na aplicação, já que não podem ser alterados para não quebrar a integridade dos dados. Em um cadastro de clientes, por exemplo, a chave primária (código ou ID) é o elemento de vínculo com outras tabelas, como pedidos, orçamentos, vendas, contas a pagar e contas a receber. O que aconteceria se o código do cliente fosse acidentalmente alterado e não houvesse um mecanismo confiável de alteração dos vínculos? Prefiro nem imaginar…

Mas qual o problema de disponibilizar a chave primária como um identificador para o usuário?

Nenhum. 🙂

No entanto, sempre devemos pensar a longo prazo, certo? Suponha que a aplicação tenha um cadastro de clientes eficiente, no qual os usuários “decoraram” alguns códigos. Eis que, em um determinado momento, a empresa decide fazer a aquisição de uma concorrente que, por sua vez, também possui uma aplicação com um cadastro de clientes da mesma natureza. Chegaremos à seguinte situação:

• Na empresa matriz, o cliente nº 10 é “Beatriz Mayumi”;
• Já na empresa adquirida, o cliente nº 10 é “André Celestino”.

Ops! Como o código é chave primária, um dos registros deverá receber um número diferente durante a migração de dados.

Ops! Os usuários da empresa adquirida já “decoraram” que o cliente nº 10 é o “André” e uma mudança poderá dificultar o trabalho ou até mesmo gerar registros incorretos em tabelas vinculadas.

Ops! As vendas já realizadas para esse cliente também deverão ser atualizadas com o código novo. Uma inconsistência na migração poderá causar transtornos para a empresa.

Não me convenceu!

Ok, então imagine que a aplicação trabalhe com bancos de dados descentralizados, ou seja, cada filial possui uma base de dados separada e que, ao final do dia, essas bases são sincronizadas para que os clientes de uma filial fiquem visíveis para as outras. Este processo de sincronização inevitavelmente irá alterar os códigos de alguns registros, pois, durante o dia, a aplicação na filial 1 não tem conhecimento de quantos registros foram cadastrados na filial 5. A sincronização irá “empilhar” os códigos, alterando-os conforme necessário. Mais uma vez: se houver um erro na sincronização, os riscos serão evidentes. Claro, cada filial pode ganhar uma faixa de códigos, mas, neste caso, os códigos perderiam a característica de serem sequenciais.

Certo, e o que você sugere? Chaves de negócio!

O que são elas?

Assim como chaves primárias, também são chaves que não se repetem e comportam-se como identificadores, mas com uma diferença: são manipuláveis pelo usuário. Chaves de negócio podem ser expostas para os usuários da aplicação, uma vez que eles próprios mantêm o controle delas, e não o banco de dados. Dessa forma, caso seja necessário modificar uma chave de negócio por um motivo qualquer, a integridade dos dados não será prejudicada, já que a chave primária (internamente utilizada pelo banco de dados) sempre será a mesma.

Pensando em um cenário prático, a chave de negócio poderia ser, por exemplo, o CPF. É um valor único, que pode ser exposto para o usuário, utilizado em consultas e, talvez o mais importante, não é controlado pelo banco de dados, como em junções.

Em um cadastro de produtos, a chave de negócio pode ser um valor “amigável” para o usuário. Os produtos X e Y podem, respectivamente, receber os valores “PRD123” e “ABC456”, enquanto suas chaves primárias seriam 1 e 2. A diferença primordial é que as chaves primárias nunca serão exibidas para os usuários. Apenas as chaves de negócio. O resultado é a garantia da integridade do banco de dados, sem contar a facilidade de controle em ambientes de migração ou sincronização.

Bom, em suma, chaves primárias devem ser controladas pelo banco de dados e chaves de negócio devem ser controlados pelo usuário. Ponto final.

Hoje fico por aqui, pessoal!
Grande abraço!