Faça essa pergunta em uma mesa de DBAs ou 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 contrário junto a um coral de apitos astecas 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. Tá crescendo linda, já passou dos 18″.

Pois é, chave artificial é o ideal pra mim, mas por quê?

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, RG ou CPF não são naturais,  são chaves  artificiais, criadas pelo governo”.

Se 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.

 

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 para 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 porque 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 estado. Eu sei onde estão, onde estiveram, para 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.

Vai lá e pergunta qual vai ser o próximo número de RG!

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 Angelina 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 conhecer o banco de dados que vai fazer o software melhor; 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 multidatabase? Acho que isso é motivo pra outro texto de busão, não este, porque meu ponto de parada está chegando e já vou puxar a cordinha aqui.

Até a próxima!