Artigos Banco de Dados Piores práticas na manipulação de BDs
Artigo do tipo Tutorial
Recursos especiais neste artigo:
Artigo no estilo Mentoring .
Porque este artigo é útil

É comum cometermos erros durante as atividades diárias de criação e manutenção de um banco de dados. Ainda mais na correria a que somos submetidos por conta de prazos muitas vezes impossíveis de serem alcançados. Neste artigo conheceremos algumas más práticas que corremos o risco de fazer no nosso dia a dia e que, por falta de atenção, continuamos a repeti-las projeto após projeto. Isso o ajudará a evitar que elas se tornem uma marca de sua atuação como profissional da área de banco de dados.

Este artigo apresenta algumas práticas que devem ser evitadas ao máximo em benefício de um bom desempenho da aplicação ao acessar o banco de dados. Desde problemas de modelagem até implementação podem ser evitados quando nos preocupamos simplesmente em adotar boas práticas.

Evitar as velhas “lendas urbanas” é crucial e ser humilde o suficiente para perguntar ou não simplesmente achar que está sempre certo pode ser a melhor de todas as práticas, pricipalmente se o projetista está iniciando no mercado de trabalho.

A teoria é extremamente importante e essencial, porém a prática muitas vezes se contrapõe à teoria e, em alguns casos, questionar o que está “solidificado” como verdade absoluta é fundamental. 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.

Chaves técnicas desnecessárias

Se já existe uma chave primária adequada, então será uma perda de tempo e espaço em disco criar uma chave técnica adicional. Este erro comum geralmente acontece como consequência da utilização da famosa coluna universal “COD”. Veja o código da criação de uma tabela na Listagem 1.

Listagem 1. Criação da tabela PAIS com uma coluna universal “COD”.


  01. CREATE TABLE PAIS
  02.   (COD          INT(11) NOT NULL AUTO_INCREMENT,
  03.    COD_PAIS_ISO CHAR(3) NOT NULL,
  04.    NOME_PAIS    VARCHAR(50) NOT NULL,
  05.    PRIMARY KEY (COD),
  06.    INDEX COD_PAIS_ISO_IX (COD_PAIS_ISO));

A coluna “COD_PAIS_ISO” já garante que cada registro da tabela “PAIS” seja sempre único, portanto, deve ser a chave primária. A adição de uma coluna “COD” é apenas disperdício de espaço na tabela de dados e de seu próprio índice. Qual o motivo de usar uma tabela separada para converter um inteiro de 4 bytes em um string de 3 bytes? O que é ainda mais grave é que a coluna “COD_PAIS_ISO” é definida como um índice não único, quando deveria ter sido definido como índice único (chave candidata), o que significa que é possível que o mesmo código de país possa aparecer mais do que uma vez na tabela.

Erros similares podem ocorrer quando lidamos com relacionamento entre as tabelas:

Relacionamento Um-para-Muitos

Vejamos o exemplo de uma tabela chamada “PEDIDO” e outra chamada “ITEM_PEDIDO” onde pode haver vários registros de “ITEM_PEDIDO” para cada registro de “PEDIDO”. Supondo que a chave primária da tabela “PEDIDO” é a coluna “COD_PEDIDO”, podemos definir a tabela “ITEM_PEDIDO” como mostra a Listagem 2.

Listagem 2. Criação da tabela ITEM_PEDIDO com uma coluna universal “COD”.


  01. CREATE TABLE ITEM_PEDIDO
  02.   (COD        INT(11) NOT NULL AUTO_INCREMENT,
  03.    COD_PEDIDO INT(11) NOT NULL,
  04.    ...,
  05.    PRIMARY KEY (COD),
  06.    INDEX ORDER_ID_IX (COD_PEDIDO));

A abordagem apresentada na Listagem 2 funciona bem, porém está disperdiçando espaço em disco porque exige dois índices que deverão ser mantidos. Veja agora o código apresentado na Listagem 3.

Listagem 3. Criação da tabela ITEM_PEDIDO sem uma coluna universal “COD”.


  01. CREATE TABLE ITEM_PEDIDO
  02.   (COD_PEDIDO INT(11) UNSIGNED NOT NULL,
  03.    COD_ITEM   SMALLINT(5) NOT NULL AUTO_INCREMENT,
  04.    ...
  05.    PRIMARY KEY (COD_PEDIDO, COD_ITEM)); ...

Quer ler esse conteúdo completo? Tenha acesso completo