Faça essa pergunta em uma mesa de DBA’s ou de arquitetos de software no bar, se afaste, pegue um chopp e assista a um episódio live de Spartacus!
Alguns dizem que se uma chave natural está disponível, ela deve ser utilizada. Eu prefiro pensar que não, não tenho o hábito de usar CPF, RG, dog-tag-id e outros como identificador de uma pessoa num banco de dados.
Meu argumento é que esses campos podem ser únicos mas não são controlados por mim, o freak dev/dba/designer/barista e, se não está sob meu controle eu não sei o que pode acontecer com ele.
Pode ser que o Bolsonado acorde um dia com desejo de colocar uma letra no início de cada RG e aí já viu… Nem disco da Xuxa sendo tocado ao contrario junto a um coral de apitos aztecas pode impedi-lo.
Já a chave artificial é minha, e sob essa ótica artificial, deixa de ser quase pejorativo para ser carinhoso.
“Essa chave aí? Eu que criei. Está crescendo linda! Já passou dos 18″.
Pois é, chave artificial é o ideal pra mim. Mas por que?
Minha obrigação não é com a realidade, mas com a porção da realidade que escolhi representar e com a representação que escolhi fazer.
Essa representação não é a realidade (não toda ela), então, por que identificar por um dado natural? O dado natural é um dado da realidade representada pelo objeto, uma propriedade.
Alguns diriam, “mas Ivo, o RG ou CPF não são naturais, são chaves artificiais, criadas pelo Governo”.
Ela não é controlada por mim – e quando digo isso, não me imagine segurando primary keys como o Tio Patinhas segura a moeda número um e rindo como um maníaco-depressivo. Quando eu falo sobre controle, falo sobre ser criada do meu lado do sistema.
https://www.youtube.com/watch?v=8To6ceNORzk
Eu também respeito as chaves artificiais porque produzem situações interessantes. Se alguém quiser mudar uma chave artificial, seus argumentos terão de ser muito bons. Vai dizer que a chave corre o risco de mudar?
“Artificial, brother… Pouco do mundo real pode afetá-la – talvez nada”.
Mas talvez ela evolua, se torne uma chave composta, ou não. Representando entidades únicas com dimensões diferentes e exclusivamente excludentes e únicas. Isso é uma outra dimensão do problema; de simples pra composto, tem muita história e motivação, vide Darwin. E baseado nesse estado posso tomar decisões de modelagem.
E mais que isso, chaves artificiais são armazenadas numericamente por que uma string teria mais questões que uma criança de 7 anos em tipos escalares gerados em auto_increment, sequencies e afins e esses recursos têm um estado. Eu sei onde estão, onde estiveram, pra onde vão e como vão. E baseado nesse estado, posso tomar decisões de modelagem.
Um pattern de identitiy, por exemplo, depende dessa chave; a instância de um objeto que implementa identitiy depende dessa chave. Se tenho uma sequence no postgresql, por exemplo, posso recuperar facilmente o próximo valor usando nextval e se estiver usando mysql, vou precisar olhar para o esquema, mas também é possível.
O lado ruim de chaves artificiais, alguém diria, é que você precisa conhecer o banco de dados para conseguir relacionar os dados em busca de informação.
Como programador você não precisa conhecer a modelagem para resolver um problema. Hummm, me fale mais sobre isso…
Como programador, você não precisa conhecer a modelagem para resolver um problema – não se os domínios são escritos de maneira concisa e existe uma layer de serviço demonstrando o relacionamento de uma maneira explícita, tipo Angeline Jolie saindo da banheira de recuperação ou aquela loira do star trek trocando de roupa.
E se o software não tem essa camada de serviço e os relacionamentos bem explicitados… Bem, não vai ser conhecendo o banco de dados que vai melhorar o software. Na realidade, conhecer o modelo do banco vai evitar que ele se torne pior.
Veja o risco: se você programar com o modelo do banco em mente, é provável que ocorram mais acoplamentos, isso porque você está relacionando dados e não os conceitos que deseja representar com orientação a objetos.
E tem a turma que considera o modelo do banco um repositório chique, e as regras (todas elas!) devem estar no código da aplicação. O que você acha disso?
Ou aquela outra turma da aplicação multi-database? Acho que isso é motivo pra outro artigo…