procergs 2015-03-25: bad smells em bancos de dados

Bad Smells (mal cheiros) em Bancos de Dados

timbiraA empresa brasileira de PostgreSQL

PROCERGS - Quarta-feira do conhecimentoPorto Alegre, 2015-03-25

http://www.timbira.com.br/

Palestrante timbira

• Fabrízio de Royes Mello• Desenvolvedor PostgreSQL• Líder do PostgreSQL Brasil• Pós-Graduando Uniritter (Agile)• @fabriziomello• http://fabriziomello.github.io

• Timbira• Consultor/Mentor/Coach• A empresa brasileira de PostgreSQL• Consultoria• Desenvolvimento• Suporte 24x7• Treinamento

Timbira - A empresa brasileira de PostgreSQL 2 / 42


http://fabriziomello.github.io

Sobre este material timbira

• esta apresentação está disponível em:http://slideshare.net/fabriziomello

• esta apresentação está sob licença Creative CommonsAtribuição 3.0 Brasil:http://www.creativecommons.org/licenses/by/3.0/br

• Embora este material tenha sido elaborado com todaprecaução, os autores não assumem quaisquerresponsabilidades por erros, omissões ou danos resultantes dautilização das informações aqui contidas.

• Se você encontrar qualquer erro, por favor reporte-o [email protected]


http://slideshare.net/fabriziomello

http://www.creativecommons.org/licenses/by/3.0/br

mailto:[email protected]

Resumo timbira

..1 Prelúdio

..2 Introdução

..3 Bad Smells

..4 Considerações Finais



Como tudo começou na minha vida... timbira

• 1993 - Basic• 1994 - CLIPPER (e um pouco de C)• 1996 - C e Pascal• 1998 - SQL - mudou minha vida ;-)• 1999 - Teoria Relacional• ...• 2004 - Web (PHP, HTML, CSS, Javascript)• ...• 2009 - Database Refactoring• ...• 2013 - Bad Smells em Bancos de Dados• ...• 2015 - Taxonomia Smells em BD



Resumo timbira

..1 Prelúdio

..2 Introdução

..3 Bad Smells




Bancos de Dados timbira

Tendem a se deteriorar ao longo do tempo. Alguns motivos:

• crescimento volume de dados/transações;• aumento natural de usuários que o utilizam;• dificuldades na evolução do schema;• estratégias de manutenção.



Bancos de Dados timbira

Tendem a se deteriorar ao longo do tempo. Alguns motivos:• crescimento volume de dados/transações;• aumento natural de usuários que o utilizam;• dificuldades na evolução do schema;• estratégias de manutenção.



Refatoração em Bancos de Dados timbira

Deterioração + Mudanças em Requisitos =Necessidade de Refatoração.

Mas não é tão simples assim, sabem porque?• além de manter comportamento também é preciso manter

informação (dados);• acoplamento com diversas origens (apps, bds, integrações,

3rd, ...)





Mas não é tão simples assim, sabem porque?

• além de manter comportamento também é preciso manterinformação (dados);

• acoplamento com diversas origens (apps, bds, integrações,3rd, ...)





Mas não é tão simples assim, sabem porque?• além de manter comportamento também é preciso manter

informação (dados);• acoplamento com diversas origens (apps, bds, integrações,

3rd, ...)



Resumo timbira

..1 Prelúdio

..2 Introdução

..3 Bad Smells




Code Smell timbira

É uma categoria comum de problema no código fonte que indicaa necessidade de refatoração. (Martin Fowler)



Database Smell timbira

Similarmente aos Code Smells existem problemas comuns embancos de dados que indicam uma potencial necessidade derefatoração. (Scott Ambler)




Multi-purpose columnSe uma coluna for utilizada para vários fins, é provável queexista um código extra para garantir que a mesma sejausada corretamente e, muitas vezes, verificando valores deuma ou mais colunas.



Multi-purpose column timbira

CREATE TABLE pessoa (id SERIAL PRIMARY KEY,tipo CHAR(1) CHECK (tipo IN ('F', 'J')),nome VARCHAR(100) NOT NULL,data DATE

);

• Se tipo = ’F’ então DATA = nascimento• Se tipo = ’J’ então DATA = inicio atividades



Multi-purpose column timbira

Sugestão(ões) Database Refactoring:• Split Column• Move Column




Multi-purpose tableQuando uma tabela é utilizada paraarmazenar vários tipos de entidades provavelmente existe umafalha de projeto.



Multi-purpose table timbira

CREATE TABLE pessoa (id SERIAL PRIMARY KEY,nome VARCHAR(100) NOT NULL,nome_fantasia VARCHAR(100),cnpj CHAR(14),cpf CHAR(11),rg CHAR(10),data DATE

);

• Se cnpj e nome_fantasia = NULL então NOME = nomepessoa física

• Se cpf e rg = NULL então NOME = razão social



Multi-purpose table timbira

Sugestão(ões) Database Refactoring:• Move Column• Split Table




Redundant dataÉ um problema sério em bases de dados porque quando odado é armazenado em vários locais, existe risco de ocorrerinconsistência.



Redundant data timbira

CREATE TABLE sys.usuario (id SERIAL PRIMARY KEY,nome VARCHAR(100) NOT NULL,endereco VARCHAR(100),numero INTEGER,complemento VARCHAR(40)

);

CREATE TABLE rh.funcionario (id SERIAL PRIMARY KEY,nome VARCHAR(100) NOT NULL,endereco VARCHAR(100),numero INTEGER,complemento VARCHAR(40)

);



Redundant data timbira

Sugestão(ões) Database Refactoring:• Merge Tables• Move Data• Drop Column




Tables with too many columnsQuando uma tabela tem muitas colunas éindicativo de falta de coesão, pois está armazenando dados devárias entidades.



Tables with too many columns timbira

CREATE TABLE pessoa (id SERIAL PRIMARY KEY,nome VARCHAR(100) NOT NULL,end_entrega VARCHAR(200),end_cobranca VARCHAR(200),end_residenc VARCHAR(200),end_profiss VARCHAR(200),fone_celular VARCHAR(20),fone_casa VARCHAR(20),fone_fax VARCHAR(20),fone_contato VARCHAR(20)

);




CREATE TABLE parametro (parametro1 VARCHAR(100),parametro2 VARCHAR(100),parametro3 VARCHAR(100),parametro4 VARCHAR(100),parametro5 VARCHAR(100),parametro6 VARCHAR(100),...parametroN VARCHAR(100)

);




Sugestão(ões) Database Refactoring:• Split Table• Move Column




Tables with too many rowsTabelas muito grandes podem nos levar a problemas deperformance.O custo (memória e tempo) para buscar ou alterar dados em umatabela varia de acordo com o número de linhas.



Tables with too many rows timbira

CREATE TABLE log (logtime TIMESTAMP,user_name TEXT,context CHAR(10),message TEXT,detail TEXT

);

CREATE TABLE log_201401() INHERITS (log);CREATE TABLE log_201402() INHERITS (log);...CREATE TABLE log_201503() INHERITS (log);



Tables with too many rows timbira

Sugestão(ões) Database Refactoring:• Split Table• Move Rows• Move Column

OBS: Em Bancos de Dados Relacionais conhecemos essa técnicacomo ”Particionamento de Tabelas”




Smart columnsColuna que armazena informações de mais de um contexto(concatenação de informações).



Smart columns timbira

CREATE TABLE processo (numero CHAR(10) PRIMARY KEY,...

);

CREATE TABLE debito (processamento CHAR(15) PRIMARY KEY...

);

• numero = 4 digitos ano + 6 digitos sequencial• processamento = 4 digitos ano + 6 digitos sequencial + 2

digitos parcela + 2 digitos total parcelas + 1 digito verificador



Smart columns timbira

Sugestão(ões) Database Refactoring:• Split Column




Phantom foreign-keyQuando uma coluna em uma tabela pode receber um valor, quedependendo de outra coluna, estabelece relacionamento de chaveestrangeira com outra tabela.



Phantom foreign-key timbira

CREATE TABLE tabela (...tipo INTEGER,codigo INTEGER,...

);

• Se TIPO = 1 entao CODIGO é ref. TABELA1• Se TIPO = 2 entao CODIGO é ref. TABELA2• Se TIPO = 3 entao CODIGO é ref. TABELA3• ...



Phantom foreign-key timbira

Sugestão(ões) Database Refactoring:• Introduce new table• Introduce table constraint• Move Column




Wrong data typeTipos de dados possuem uma assinatura, que descreve asvalidações mínimas para seu uso.



Wrong data type timbira

CREATE TABLE pessoa (id SERIAL PRIMARY KEY,nome VARCHAR(100) NOT NULL,cnpj CHAR(14),cpf CHAR(11),rg CHAR(10)

);

CREATE TABLE atributo_dinamico (nome VARCHAR(100),tipo INTEGER,valor TEXT

);

• CNPJ, CPF e RG não são números?• VALOR é um campo ”flex”, WTF?



Wrong data type timbira

Sugestão(ões) Database Refactoring:• Replace column




Trigger SpaghettiQuando existe uma trigger em uma tabela A que realiza operações(insert/update/delete) em uma tabela B e esta possui trigger que,dependendo de condições (valores das colunas), faz operações natabela C, onde também existe outra trigger, que tambémdependendo de algumas condições faz operações na tabela A, ondede certa forma garante que nao seja gerado um loop infinito.WTF??




Trigger SpaghettiSe você tem isso, saiba que existe um lugarzinho especial reservadopra você ”In the Hell” !!!Sério... NÂO FAÇA ISSO!!!.




Smells detectados pela minha experiência (ainda não estãona literatura):

• Phantom foreign-key• Wrong data type• Trigger Spaghetti




Fear of changeDentre os database smells citados, devemos ter atenção especial aeste, pois pode ser considerado o pior de todos, pois:

• inibe a inovação,• reduz a efetividade,• produz ainda mais bagunça e• ao longo do tempo a situação fica cada vez pior.




Fear of changeA solução para esse smell é mais uma questão depostura positiva do time aliada a adoção de boas práticas, taiscomo:

• database refactoring;• database unit and regression tests;• database continuous integration;• schema versioning.



Resumo timbira

..1 Prelúdio

..2 Introdução

..3 Bad Smells




Considerações Finais timbira

Área com campo vasto a ser explorado• Taxonomia dos Database Smells• Database Smells primitivos e compostos

Explorar outras formas de detecção• métricas, visualização, engenharia reversa, dependência cíclica

Ferramentas de apoio



Dúvidas timbira

?

Fabrízio de Royes Mello@fabriziomello

[email protected]@gmail.com

http://www.timbira.com.brhttp://slideshare.net/fabriziomello



http://www.timbira.com.br

http://slideshare.net/fabriziomello

Referências timbira

• Refactoring Improving the Desing of Existing Code (MartinFowler)

• Refactoring Databases: Evolutionary Database Design (ScottAmbler e Pramod Sadalage)

• http://martinfowler.com/books/refactoring.html• http:

//agiledata.org/essays/databaseRefactoring.html• http://www.agiledata.org/essays/

databaseRefactoringSmells.html



http://martinfowler.com/books/refactoring.html

http://agiledata.org/essays/databaseRefactoring.html

http://agiledata.org/essays/databaseRefactoring.html

http://www.agiledata.org/essays/databaseRefactoringSmells.html

http://www.agiledata.org/essays/databaseRefactoringSmells.html

procergs 2015-03-25: bad smells em bancos de dados

Technology