Banco de Dados

1 jun, 2015

Identificadores artificiais ou naturais no banco de dados?

Publicidade

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.

angelina_jolie_nude_ass_wanted_4

carol_04

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…