Changes between Initial Version and Version 1 of WF/PadroesdeNomenclaturaparaBancosdeDados


Ignore:
Timestamp:
07/24/07 15:01:39 (17 years ago)
Author:
trac
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WF/PadroesdeNomenclaturaparaBancosdeDados

    v1 v1  
     1== Normas gerais == 
     2  
     3 
     4 * Use letras maiúsculas para palavras reservadas (sintaxe) SQL. 
     5 
     6 * Use letras minúsculas para elementos de negócio (particulares do projeto em desenvolvimento): 
     7  * eliminar a dúvida sobre qual a "caixa" correta assim como outros erros relacionados. 
     8  * aumenta a velocidade de escrita e exatidão. 
     9  * diferencia nomes de tabelas e campos da sintaxe com caixa alta do SQL. 
     10 
     11 * Separe palavras e prefixos com "_" (underline), nunca use espaços. 
     12  * melhora legibilidade (ex: nome_livro e nomelivro). 
     13  * evita a necessidade de envolver nomes com colchetes (ex: [nome livro] oh 'nome livro'). 
     14  * maior independência de plataforma. 
     15 * Evite usar números. 
     16 * Procure identar os comandos SQL, principalmente se os mesmos forem extensos. 
     17  * Melhora a legibilidade do código 
     18 
     19{{{ 
     20 
     21   Exemplo sem identação: 
     22 
     23   SELECT filial_id, produto_id, pro_descricao, pro_valor_unitario FROM produto WHERE filial_id = 2 AND pro_valor_unitario > 100; 
     24 
     25   Exemplo com identação: 
     26 
     27   SELECT filial_id, produto_id, pro_descricao, pro_valor_unitario 
     28     FROM  produto 
     29     WHERE filial_id          = 2 
     30     AND   pro_valor_unitario > 100; 
     31 
     32}}} 
     33 
     34== Tabelas == 
     35 
     36 * Escolha nomes sem ambiguidade, curtos, não usando mais que duas palavras. 
     37  * distingue tabelas facilmente. 
     38  * facilita nomear campos únicos assim como tabelas de metadados. 
     39 
     40 * Use nomes no singular, nunca plural. 
     41  * promove consistência com a nomenclatura de campos de chave primárias e tabelas de metadados. 
     42  * garante ordenação alfabética de uma tabela antes de suas tabelas de metadados ou relacionadas. 
     43  * evita confusão de regras de plural do português ou inglês. 
     44  * estrutura SQL mais "gramatical" (ex: SELECT activity.activity_name --ao invés de-- SELECT activities.activity_name). 
     45 
     46 * Evite nomes com acrônimos, abreviados ou concatenados. 
     47  * provê arquitetura auto-documentável. 
     48  * facilita tanto para desenvolvedores quanto para não-desenvolvedores lerem e entenderem. 
     49 
     50 * Prefixe as tabelas de metadados (lookup tables) com o nome das tabelas a que elas se relacionam. 
     51  * agrupa tabelas relacionadas (ex: activity_status, activity_type, etc). 
     52  * evita conflitos de nomes de tabelas de metadados de diferentes entidades. 
     53 
     54 * Para uma tabela associativa (n:n), concatene o nome das duas tabelas envolvidas: 
     55  * ordena a tabela resultado da junção com as entidades relacionadas. 
     56  * expressa o propósito de composição da tabela. 
     57  * deve ser evitado quando houver muitas tabelas com junção para as mesmas entidades originais. 
     58 
     59 
     60== Campos/Colunas == 
     61 
     62 
     63 
     64 * A chave primária deve ter o nome da tabela com o sufixo "_id". 
     65  * permite que a chave primária seja deduzida ou lembrada a partir apenas do nome da tabela (ex: chave primária da tabela "produto" seria "produto_id". 
     66  * consistência com o nome da chave primária. 
     67  * evita a necessidade de usar apelidos (alias) na programação. 
     68  * para tabelas que possuem mais de um campo compondo a chave primária, essa regra não se aplica, sendo que os campos poderão continuar tendo o sufixo "_id", porém o seu nome que antecede tal sufixo terá que ser outro diferente do nome da tabela. Ex: tabela IMOBILIZADO, PK = patrimonio_id + ano_id. 
     69  * quando a chave primária é composta por campos FK, os mesmos permanecerão com os nomes dos campos PK das tabelas relacionadas. Ex: tabela ITEM_NOTA_FISCAL, a PK seria nota_fiscal_id e item_nota_fiscal_id, onde o campo nota_fiscal_id é a FK que vem de outra tabela e o campo item_nota_fiscal_id é da própria tabela em questão, e ambos juntos formam a PK. 
     70 
     71 * Chaves estrangeiras devem ter o mesmo nome das chaves primárias às quais elas se referem. 
     72  * faz com que as tabelas às quais elas se referem completamente óbvio. 
     73  * se houver múltiplas chaves estrangeiras se referenciando a uma mesma tabela, prefixe o campo da chave estrangeira com um adjetivo descritivo apropriado (adjetivo_nome_campo, ex: technical_funcionario_id).