Os dez erros comuns em projetos de banco de dados - Revista SQL Magazine 101 - Parte 1

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Este artigo apresenta os dez erros mais comuns no processo de modelagem de um banco de dados, tanto no tocante à modelagem em si, quanto à manutenção e também o desempenho geral do banco de dados.

Artigo no estilo Curso

De que se trata o artigo

Este artigo apresenta os dez erros mais comuns no processo de modelagem de um banco de dados, tanto no tocante à modelagem em si, quanto à manutenção e também o desempenho geral do banco de dados. Neste contexto, o conteúdo deste artigo serve para que o arquiteto de dados reflita sobre algumas más práticas de modelagem de dados para que possa evitá-las em seus projetos.


Em que situação o tema é útil

Durante o desenvolvimento de um modelo de dados, evitar certos vícios e práticas pouco adequadas é especialmente útil para que o projeto como um todo alcance o êxito desejado ou que, ao menos, o retrabalho seja o mínimo possível.

Resumo DevMan

Durante o desenvolvimento de um projeto de banco de dados é comum nos depararmos com situações realmente assustadoras. Muitas dessas situações estão diretamente ligadas a erros que os arquitetos comentem mais frequentemente do que gostaríamos.

É fato que se pretendêssemos escrever sobre todos os erros comuns durante o projeto/modelagem de banco de dados, teríamos assunto para um livro inteiro, e com direito a um segundo livro. Como a intenção não é a de escrever um livro, separamos os dez erros mais comuns e que, acreditem, podem ser totalmente evitados.

Neste primeiro artigo serão abordados os cinco primeiros, que passam por problemas de má concepção e planejamento do projeto, problemas típicos de falta de normalização, falta completa de padrões de nomenclatura, total falta de documentação e chegando ao problema de utilização de uma única tabela para armazenar todos os valores de domínio.

Sem dúvida nenhuma este artigo não traz a solução para todos os problemas de projeto de banco de dados, mas leva o leitor a uma reflexão profunda do que ele pode evitar para obter um projeto pleno e o mais próximo possível do êxito.

Sem a menor sombra de dúvidas a internet se tornou uma das principais fontes de consulta do mundo moderno. Nem me lembro mais qual foi a última vez que entrei em uma biblioteca para pesquisar algo. Sim, continuo comprando livros. Por sinal adoro perder algumas horas em uma boa livraria, principalmente as que possuem livros técnicos.

Mas não podemos negar que a quantidade de material de boa qualidade e de fácil acesso que encontramos na internet é vasta e interessante.

E justamente em uma dessas navegadas encontrei um artigo interessante escrito por Louis Davidson, um Arquiteto de Dados (DA – Data Architect, em inglês) com mais de 15 anos de experiência em Bancos de Dados (ver seção Referências Bibliográficas), que fala sobre os dez erros mais comuns no projeto de Bancos de Dados. Mas é claro que não poderia simplesmente fazer uma tradução. Me preocupei em agregar informações ao artigo e torná-lo mais agradável e rico para você, leitor da SQL Magazine.

Se o projeto de Banco de Dados é feito de maneira correta, então o desenvolvimento, implementação e, consequentemente, o desempenho geral do banco de dados terá poucos problemas. Um banco de dados bem projetado “simplesmente funciona”. Há um pequeno número de erros no projeto de banco de dados que transformam a vida de desenvolvedores, gerentes e DBAs em um imenso inferno astral.

Este artigo trata dos dez piores erros que são cometidos de uma maneira até que comum em grande parte dos projetos de bancos de dados.

Nenhuma lista de erros jamais será definitiva. As pessoas, algumas vezes, fazem um monte de coisas estúpidas para garantir um prazo ou até mesmo por pura preguiça, inclusive eu. Conheço muita gente assim, acredite.

Esta lista reflete simplesmente os erros de projeto de banco de dados que nos deparamos com uma certa frequência, infelizmente.

É importante salientar que todos nós estamos sujeitos a comenter equívocos e mesmo implementar práticas, como dizer, “pouco ortodoxas” que podem não surtir o efeito desejado. É claro que sempre que escrevemos qualquer artigo, seja para a revista ou para o blog, procuramos apresentar sempre as melhores práticas e ensinar sempre o melhor possível.

O mais importante é que, após ler este artigo, você tenha sempre uma pequena voz interior lhe alertando sempre que estiver prestes a cometer um destes equívocos.

Vejamos então a tão falada lista:

1. Má concepção / planejamento;

2. Ignorar a normalização;

3. Falta de padrões de nomenclatura;

4. Falta de documentação;

5. Uma tabela para armazenar todos os valores de domínio;

6. Usar coluna auto-incremento como sua única chave;

7. Não utilizar as características do SQL para proteger a integridade de dados;

8. Não usar stored procedures (ver Nota DevMan 1) para acessar dados;

9. Tentativa de construção de objetos genéricos;

10. Falta de testes.

Nota DevMan 1: Stored Procedures

Uma stored procedure (procedimento armazenado) é uma sub-rotina disponível para aplicativos que acessam um sistema de banco de dados relacional. Uma stored procedure (muitas vezes chamada de proc, sproc, stopro, StoredProc, sp ou SP) é, na verdade, um código armazenado no dicionário de dados do banco de dados.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?