Identificadores artificiais ou naturais no banco de dados?

Faça essa pergunta em uma mesa de DBA’s 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 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 ai?… Eu que criei. Ta crescendo linda, já passou dos 18”.

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

the-treachery-of-images-this-is-not-a-pipe-1948(2)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 porque 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 sao naturais,  sao chaves  artificial, criada pelo governo”.

tio-patinhasSe 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 uma hauahuahauahua maníaco-depressivo. Quando eu falo sobre controle, falo sobre ser criada do meu lado do sistema.

Eu também respeito as chaves artificiais por que produzem situações interessantes. Se alguém quiser mudar uma chave artificial seus argumentos terão de ser fodasticos, 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 tem 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.

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 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 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 por que 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 texto de busão, não esse, por que meu ponto de parada ta chegando e já vou puxar a cordinha aqui.

Bjunda no ombro!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s