Banco de Dados Evolutivo – Parte 3

Nesse próximo post da série Banco de Dados evolutivo iremos entender acerca dos diferentes tipos de refatorações de bancos de dados. Veremos também uma melhor prática para utilização das SandBox (para mais informações sobre as SandBox, leia Banco de Dados Evolutivo – Parte 2)


Refatorações de Banco de Dados

Toda e qualquer alteração feita na base de dados é denominada refatoração. Essa técnica de refatoração do SGBD torna-se complexa porque no banco existem três diferentes mudanças que ora são feitas em conjunto, ora não. São elas:

  1. Alteração no Schema de Banco de Dados – Mudanças executas com base em queries DDL (Data Definition Language);
  2. Alteração de Dados do SGBD – Mudanças executadas com base em queries DML (Data Manipulation Language);
  3. Alteração de Acessos do Banco de Dados – Mudanças executadas com base em queries DCL (Data Control Language).

Muitas refatorações, tais como adicionar uma coluna, podem ser feitas sem ser preciso atualizar áreas do código da aplicação. Por outro lado, existem mudanças que são caracterizadas como alterações destrutivas. Essas refatorações são conhecidas dessa forma porque sua implementação pode fazer com que surjam erros no sistema. Como exemplo teríamos tornar uma coluna NULL como NOT NULL.

Alterações destrutivas precisam de um pouco mais de cuidado cujo grau de atenção irá depender do quanto a mudança é prejudicial ao ambiente. O importante é escolher em conjunto com o time um procedimento apropriado para cada tipo de mudança. Se houver um controle adequado do sistema, mesmo que ocorra algum problema, não será difícil revertê-lo e corrigi-lo.

Atualização automática e simuntânea das SandBox

Uma boa prática para o conceito de banco de dados evolutivo é sempre atualizar automaticamente todas as sandbox quando o banco de dados master for alterado. O mesmo script que atualiza a base de dados central atualizará todas as instancias de banco de dados dos desenvolvedores. Dessa maneira há uma impossibilidade de um desenvolvedor executar um commit em uma alteração e modificar a base master que já havia sido atualizada por outro programador.

No próximo post veremos como utilizar todos esses conceitos listados através da ferramenta de versionamento de banco de dados Liquibase.


Para saber mais, leia: Banco de Dados Evolutivo – Parte 1 Banco de Dados Evolutivo – Parte 2

Anúncios

3 comentários sobre “Banco de Dados Evolutivo – Parte 3

  1. Pingback: Banco de Dados Evolutivo – Parte 4 | Arthur Luz | Data's Light

  2. Pingback: Banco de Dados Evolutivo – Parte 6 | Arthur Luz | Data's Light

  3. Pingback: Banco de Dados Evolutivo – Parte 14 | Arthur Luz | Data's Light

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s