| | 1 | = Padrões para Banco de Dados = |
| | 2 | |
| | 3 | == Normas gerais == |
| | 4 | |
| | 5 | * Use letras maiúsculas para palavras reservadas (sintaxe) SQL. |
| | 6 | |
| | 7 | * Use letras minúsculas para elementos de negócio (particulares do projeto em desenvolvimento): |
| | 8 | * elimina a dúvida sobre qual a "caixa" correta assim como outros erros relacionados. |
| | 9 | * aumenta a velocidade de escrita e exatidão. |
| | 10 | * diferencia nomes de tabelas e campos da sintaxe com caixa alta do SQL. |
| | 11 | |
| | 12 | * Separe palavras e prefixos com "_" (underline), nunca use espaços. |
| | 13 | * melhora legibilidade (ex: nome_livro). |
| | 14 | * evita a necessidade de envolver nomes com colchetes (ex: [nome livro] ou 'nome livro'). |
| | 15 | * maior independência de plataforma. |
| | 16 | |
| | 17 | * Evite usar números. |
| | 18 | |
| | 19 | * Procure identar os comandos SQL, principalmente se os mesmos forem extensos. |
| | 20 | * Melhora a legibilidade do código |
| | 21 | |
| | 22 | {{{ |
| | 23 | |
| | 24 | Exemplo sem identação: |
| | 25 | |
| | 26 | SELECT filial_id, produto_id, pro_descricao, pro_valor_unitario FROM produto WHERE filial_id = 2 |
| | 27 | AND pro_valor_unitario > 100; |
| | 28 | |
| | 29 | Exemplo com identação: |
| | 30 | |
| | 31 | SELECT filial_id, produto_id, pro_descricao, pro_valor_unitario |
| | 32 | FROM produto |
| | 33 | WHERE filial_id = 2 |
| | 34 | AND pro_valor_unitario > 100; |
| | 35 | |
| | 36 | }}} |
| | 37 | |
| | 38 | == Tabelas == |
| | 39 | |
| | 40 | * Escolha nomes sem ambiguidade, curtos, não usando mais que duas palavras. |
| | 41 | * distingue tabelas facilmente; |
| | 42 | * facilita nomear campos únicos assim como tabelas de metadados. |
| | 43 | |
| | 44 | * Use nomes no singular, nunca plural. |
| | 45 | * promove consistência com a nomenclatura de campos de chave primárias e tabelas de metadados; |
| | 46 | * garante ordenação alfabética de uma tabela antes de suas tabelas de metadados ou relacionadas; |
| | 47 | * evita confusão de regras de plural do português ou inglês; |
| | 48 | * estrutura SQL mais "gramatical" (ex: SELECT activity.activity_name --ao invés de-- SELECT activities.activity_name). |
| | 49 | |
| | 50 | * Evite nomes com acrônimos, abreviados ou concatenados. |
| | 51 | * provê arquitetura auto-documentável; |
| | 52 | * facilita a leitura e o entendimento, tanto para desenvolvedores quanto para não-desenvolvedores. |
| | 53 | |
| | 54 | * Prefixe as tabelas de metadados (lookup tables) com o nome das tabelas a que elas se relacionam. |
| | 55 | * agrupa tabelas relacionadas (ex: activity_status, activity_type, etc); |
| | 56 | * evita conflitos de nomes de tabelas de metadados de diferentes entidades. |
| | 57 | |
| | 58 | * Para uma tabela associativa (n:n), concatene o nome das duas tabelas envolvidas: |
| | 59 | * expressa o propósito de composição da tabela; |
| | 60 | * esta regra não se aplica quando houver mais de uma tabela associativa para as mesmas entidades originais. |
| | 61 | |
| | 62 | * Crie comentários para a tabela e para as colunas: |
| | 63 | * facilita a compreensão do propósito da tabela; |
| | 64 | * explica o conteúdo presente em uma coluna. |
| | 65 | |
| | 66 | == !Campos/Colunas == |
| | 67 | |
| | 68 | * A chave primária deve ter o nome da tabela com o prefixo "pk_". |
| | 69 | * 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 "pk_produto". |
| | 70 | * consistência com o nome da chave primária. |
| | 71 | * evita a necessidade de usar apelidos (alias) na programação. |
| | 72 | * 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 prefixo "pk_", porém o nome que sucede o prefixo "Pk_" terá que ser outro diferente do nome da tabela. Ex: tabela "imobilizado", PK = pk_patrimonio + pk_ano; |
| | 73 | * 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 pk_nota_fiscal e pk_item_nota_fiscal, onde o campo pk_nota_fiscal é a FK que vem de outra tabela e o campo pk_item_nota_fiscal é da própria tabela em questão, e ambos juntos formam a PK |
| | 74 | |
| | 75 | * Chaves estrangeiras devem ter o mesmo nome das chaves primárias às quais elas se referem. |
| | 76 | * faz com que as tabelas às quais elas se referem fique óbvio; |
| | 77 | * se houver múltiplas chaves estrangeiras se referenciando a uma mesma tabela, prefixe o campo da chave estrangeira com um nome descritivo apropriado (adjetivo_nome_campo, ex: fk_titular_funcionario_id, fk_substituto_funcionario). |
| | 78 | |
| | 79 | == Restrições (Constraints) == |
| | 80 | |
| | 81 | * 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"). |
| | 82 | * O nome das chaves estrangeiras deverão ser formados pelo nome da tabela + o sufixo _fknn, onde 'nn' é um sequencia começando em '01'. (Ex: reserva_sala_fk01). |
| | 83 | * O objetivo de nomear as chaves estrangeiras em sequência é simplificar a escrita. |
| | 84 | |
| | 85 | == Índices == |
| | 86 | |
| | 87 | * O nome de um índice deverá ser formado pelo nome da tabela + campo indexado + sufixo _idx. (Ex: ocorrencia_servico_id_idx). |
