Artigos Banco de Dados Piores práticas em bancos de dados
Artigo do tipo Teórico
Recursos especiais neste artigo:
Artigo no estilo Mentoring
Piores Práticas em Bancos de Dados
No decorrer de uma carreira, todo profissional de banco de dados irá se deparar com diversos outros profissionais, tanto de banco de dados quanto programadores e desenvolvedores. E, da mesma forma que existem diversos profissionais das mais variadas áreas, há também diversos níveis de profissionais em cada uma dessas áreas.

Este artigo aborda alguns conceitos que deveriam (e outros que nunca deveriam) ser seguidos ou mesmo melhor estudados para garantir um bom desempenho do banco de dados e da aplicação como um todo. Assim, este artigo trata de uma seção de mentoring, onde são apresentadas situações hipotéticas, porém comuns, em que as boas práticas não são utilizadas e então o profissional de bando de dados é orientado a como proceder para que o sistema obtenha eficiência e eficácia.

Em que situação o tema é útil
Durante a modelagem de dados muitas decisões são tomadas para, aparentemente, poupar esforços de digitação ou economizar algum espaço de armazenamento ou até mesmo utilizar uma nova funcionalidade do Sistema de Gerenciamento de Banco de Dados, porém estas mesmas decisões podem gerar um impacto extremamente negativo e ocasionar retrabalhos ou mesmo esforços extra para contornar o problema causado pela “economia” mal analisada. Para evitar este tipo de problema é que o assunto discutido neste artigo se mostra bastante útil.

Durante uma carreira na área de TI o profissional terá visto e/ou participado de projetos de muitas aplicações que utilizam diferentes linguagens, diferentes paradigmas e sistemas de armazenamento diferentes.

Para aqueles profissionais que já estão na batalha há um certo tempo, alguns dos sistemas de armazenamento foram arquivos simples (os famosos flat files), arquivos indexados, bancos de dados hierárquicos, bancos de dados de rede e bancos de dados relacionais. Principalmente a partir do final da década de 80, a grande maioria do trabalho passou a ser com bancos de dados relacionais, que são acessados utilizando a linguagem SQL.

SQL (Structured Query Language – Linguagem Estruturada de Consulta) é uma linguagem de programação de propósito especial projetado para gerenciar dados armazenados em um sistema de gerenciamento de banco de dados relacional.

Originalmente baseado em álgebra relacional e cálculo relacional de tupla, SQL consiste em uma linguagem de definição de dados e uma linguagem de manipulação de dados. O escopo do SQL inclui inserção de dados, consulta, atualização e exclusão, criação e modificação do esquema, e controle de acesso de dados. Embora o SQL seja frequentemente descrito como, e em grande parte é uma linguagem declarativa (4GL – ver BOX 1), ela também inclui elementos procedurais.

SQL foi uma das primeiras linguagens comerciais para o modelo relacional de Edgar F. Codd, conforme descrito em seu influente artigo de 1970 “Um Modelo de Dados Relacional para Grandes Bancos de Dados Compartilhados” (“A Relational Model of Data for Large Shared Data Banks”). Apesar de não totalmente aderente ao modelo relacional, como descrito por Codd, tornou-se a linguagem de banco de dados mais utilizada.

SQL se tornou um padrão do Instituto Nacional Americano de Padrões (ANSI - American National Standards Institute) em 1986, e da Organização Internacional de Padrões (ISO - International Organization for Standards) em 1987. Desde então, o padrão foi aprimorado várias vezes com recursos adicionais. Mas o código não é totalmente portável entre os diferentes sistemas de banco de dados. Os diferentes fabricantes não seguem perfeitamente o padrão, eles adicionam extensões, e o padrão é por vezes ambíguo.

SQL foi inicialmente desenvolvido pela IBM por Donald D. Chamberlin e Raymond F. Boyce no início de 1970. Esta versão, chamada inicialmente SEQUEL (Structured English Query Language – Linguagem Estruturada de Consulta em Inglês), foi projetada para manipular e recuperar dados armazenados no sistema da IBM quase-relacional de gerenciamento de dados System R, que um grupo do laboratório de pesquisa da IBM em San Jose havia desenvolvido durante a década de 1970. A sigla SEQUEL foi posteriormente alterada para SQL porque “SEQUEL” é uma marca comercial da empresa de aeronaves Hawker Siddeley sediada no Reino Unido.

No final de 1970, a empresa Relational Software (hoje Oracle Corporation) viu o potencial dos conceitos descritos por Codd, Chamberlin e Boyce e desenvolveu seu próprio RDBMS baseado em SQL com aspirações de vendê-lo para a Marinha dos EUA, Agência Central de Inteligência e outras agências do governo dos EUA. Em junho de 1979, a Relational Software lançou a primeira aplicação disponível no mercado de SQL, Oracle V2 (Versão 2) para computadores VAX.

Depois de testar o SQL em ambientes de teste do cliente para determinar a utilidade e praticidade do sistema, a IBM começou a desenvolver produtos comerciais baseados em seu protótipo System R incluindo System/38, SQL/DS e DB2, que estavam disponíveis comercialmente em 1979, 1981 e 1983, respectivamente.

Embora a SQL esteja em constante evolução, com novos recursos e novas formas de fazer as coisas, há alguns conceitos que têm resistido ao teste do tempo e tentativas de suplantá-los com ideias novas e “bacanas”, que muitas vezes têm consequências inesperadas.

Existem alguns profissionais que apenas projetam sistemas, mas nunca os implementam, pois esta tarefa é passada para outra equipe. Infelizmente, às vezes, estes profissionais projetam coisas que realmente não podem ser implementadas sem um esforço imenso. É muito importante que haja uma certa experiência com implementações, pois desta forma o profissional consegue avaliar as consequências de cada decisão durante o projeto.

...
Quer ler esse conteúdo completo? Tenha acesso completo