Bad Smells (mal cheiros) em Bancos de Dados
-
Fabrízio de Royes Mello
Atualmente, como Especialista de Banco de Dados na Timbira, ajudo pessoas e times a tirar máximo proveito do PostgreSQL. Realizo trabalhos voluntários para Comunidade Brasileira de PostgreSQL (listas discussão, organização de eventos e administração). Também ajudo o PostgreSQL Global Development Group (PGDG) na implementação de algumas funcionalidades e revisão de patches (git.postgresql.org).
Uma estrutura de um banco de dados, diferentemente de um software, tende a deteriorar com o passar do tempo. Dentre várias causas podemos citar: (i) o crescimento progressivo do volume de dados devido ao aumento natural de usuários que o utilizam, e (ii) o tempo de uso, tornando um modelo de dados que no início era eficiente para solução proposta em um modelo ineficiente e defasado.
Essa deterioração aliada a mudanças em requisitos de negócio exigem refatorações tanto no software quanto em seus bancos de dados. Porém a refatoração de um banco de dados é mais complexa que a de um software, pois: (i) além de manter comportamento também é necessário manter as informações (dados) e (ii) acoplamento com diversas origens (outras apps, frameworks, integrações, etc).
Devido a essas dificuldades a evolução de uma estrutura de banco de dados torna-se um desafio, ocorrendo assim um fenômeno conhecido como Bad Smells (mal cheiros), da mesma forma que ocorre com o código de um software. Em software um code smell (bad smell) é uma categoria comum de problema no código fonte que indica a necessidade de refatoração, e o mesmo ocorre com bancos de dados, onde são chamados database smells.
Alguns exemplos de database smells:
* Multi-purpose column
* Multi-purpose table
* Redundant data
* Tables with many columns
* "Smart" columns
* Lack of constraints
* Fear of change
Dentre os database smells citados acima, devemos ter atenção especial ao "Fear of change", pois pode ser considerado o pior de todos, pois:
* inibe inovação,
* reduz efetividade,
* produz ainda mais bagunça
* ao longo do tempo a situação fica cada vez pior.
Lembra do valor "Coragem" do XP (eXtreme Programming)? Mudança é algo que deve ser considerado natural e irá acontecer em projetos de software, isso é um fato, não podemos fugir disso, então precisamos das práticas e ferramentas adequadas para que a mudança não seja um entrave na evolução do seu projeto, e sim algo natural e, de certa forma, trivial para s
Essa deterioração aliada a mudanças em requisitos de negócio exigem refatorações tanto no software quanto em seus bancos de dados. Porém a refatoração de um banco de dados é mais complexa que a de um software, pois: (i) além de manter comportamento também é necessário manter as informações (dados) e (ii) acoplamento com diversas origens (outras apps, frameworks, integrações, etc).
Devido a essas dificuldades a evolução de uma estrutura de banco de dados torna-se um desafio, ocorrendo assim um fenômeno conhecido como Bad Smells (mal cheiros), da mesma forma que ocorre com o código de um software. Em software um code smell (bad smell) é uma categoria comum de problema no código fonte que indica a necessidade de refatoração, e o mesmo ocorre com bancos de dados, onde são chamados database smells.
Alguns exemplos de database smells:
* Multi-purpose column
* Multi-purpose table
* Redundant data
* Tables with many columns
* "Smart" columns
* Lack of constraints
* Fear of change
Dentre os database smells citados acima, devemos ter atenção especial ao "Fear of change", pois pode ser considerado o pior de todos, pois:
* inibe inovação,
* reduz efetividade,
* produz ainda mais bagunça
* ao longo do tempo a situação fica cada vez pior.
Lembra do valor "Coragem" do XP (eXtreme Programming)? Mudança é algo que deve ser considerado natural e irá acontecer em projetos de software, isso é um fato, não podemos fugir disso, então precisamos das práticas e ferramentas adequadas para que a mudança não seja um entrave na evolução do seu projeto, e sim algo natural e, de certa forma, trivial para s