Changes between Version 5 and Version 6 of WF/PadroesdeNomenclaturaparaBancosdeDados
- Timestamp:
- 06/19/09 17:14:46 (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WF/PadroesdeNomenclaturaparaBancosdeDados
v5 v6 7 7 8 8 * Use letras minúsculas para elementos de negócio (particulares do projeto em desenvolvimento): 9 * elimina ra dúvida sobre qual a "caixa" correta assim como outros erros relacionados.9 * elimina a dúvida sobre qual a "caixa" correta assim como outros erros relacionados. 10 10 * aumenta a velocidade de escrita e exatidão. 11 11 * diferencia nomes de tabelas e campos da sintaxe com caixa alta do SQL. 12 12 13 13 * Separe palavras e prefixos com "_" (underline), nunca use espaços. 14 * melhora legibilidade (ex: nome_livro e nomelivro).15 * evita a necessidade de envolver nomes com colchetes (ex: [nome livro] o h'nome livro').14 * melhora legibilidade (ex: nome_livro). 15 * evita a necessidade de envolver nomes com colchetes (ex: [nome livro] ou 'nome livro'). 16 16 * maior independência de plataforma. 17 17 18 * Evite usar números. 19 18 20 * Procure identar os comandos SQL, principalmente se os mesmos forem extensos. 19 21 * Melhora a legibilidade do código … … 56 58 57 59 * Para uma tabela associativa (n:n), concatene o nome das duas tabelas envolvidas: 58 * ordena a tabela resultado da junção com as entidades relacionadas.59 60 * expressa o propósito de composição da tabela. 60 * deve ser evitado quando houver muitas tabelas com junção para as mesmas entidades originais. 61 61 * Esta regra não se aplica quando houver mais de uma tabela associativa para as mesmas entidades originais 62 62 63 63 == Campos/Colunas == 64 65 66 64 67 65 * A chave primária deve ter o nome da tabela com o sufixo "_id". … … 69 67 * consistência com o nome da chave primária. 70 68 * evita a necessidade de usar apelidos (alias) na programação. 71 * 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.72 * 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.69 * 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. 70 * 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 73 71 74 72 * Chaves estrangeiras devem ter o mesmo nome das chaves primárias às quais elas se referem. 75 73 * faz com que as tabelas às quais elas se referem completamente óbvio. 76 74 * 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). 75 76 == Restrições (Constraints) == 77 78 * O nome da chave primária deverá ser formado pelo nome da tabela, acrescido do sufixo _pkey. (Ex: tabela "reserva_sala", chave "reserva_sala_pkey"). 79 * O nome das chaves estrangeiras deverão ser formados pelo nome da tabela destino + campo(s) id + o sufixo _fkey. (Ex: reserva_reserva_id_fkey). 80 81 == Índices == 82 83 * O nome de um índice deverá ser formado pelo nome da tabela + campo indexado + sufixo _idx. (Ex: ocorrencia_servico_id_idx).
