Padronização de nomeclatura de banco de dados

Eis uma coisa complicada. Cada programador, analista ou DBA tem uma forma de entender e montar uma estrutura de banco de dados.

Lembro-me do tempo do CLIPPER onde os arquivos DBF´s e NTX´s eram bem limitados. Tinha um esquema comumente chamado de 8.3 para nome de tabelas e quantidade limitada de caracteres para nome de campos. Tinhamos que fazer verdadeiros milagres no momento de dar nome as campos das tabelas. Haja abreviações. Era preciso definir padrões para as abreviações, bem documentados, para que outro programador pudesse entender, ou mesmo, o próprio desenvolvedor entendesse o que havia feito na hora de dar manutenção no sistema.

Com o avanço tecnológico, muita coisa mudou nessa área. Por exemplo, a evolução dos sistemas operacionais nos permite indentificar com mais clareza os arquivos. De igual forma, os bancos de dados relacionais. Houve um aumento no tamanho permitido para nome de tabelas, campos, chaves, etc.

Porém, com todo esse avanço, vejo que muita gente quer preservar algumas características legadas para dar nome às entidades relacionais do banco de dados. Por exemplo: um campo da tabela que servirá pra guardar endereço, há quem utilize END para nome do campo; um campo utilizado pra guardar a razão social, ha quem utilize RAZ_SOC para nomear o campo. Eu pergunto: PRA QUE TANTA ABREVIAÇÃO DE NOMES, HOJE EM DIA? Se o banco permite, porque não utilizar os nomes sem abreviações desnecessárias?! As justificativas apresentadas são as mais variadas. Mas não ouvi nenhuma que seja realmente convicente. Inclusive, se for uma prática do leitor usar essaS abreviaturas nos bancos de dados atuais, peço que registre um comentário explicando o seu motivo pra abreviar.

Mas não é só essa questão. Por exemplo, alguns analistas tem o costume de identificar os tipos de entidade no nome da entidade. Por exemplo: A tabela de usuários será nomada assim: TB_USUARIO. Uma vez eu vi uma situação que achei um excesso. Uma tabela com o seguinte nome de campo: TB_USUARIO_LOGIN, ou seja, o nome da tabala compondo o nome do campo. Essa prática é pouco indicada pra quem trabalha com orientação a objeto. Quem trabalha mapeamento O/R (como no Hibernate, por exemplo) terá um trabalho dobrado pra reduzir estes nomes; para adequar os nomes das tabelas à definição das classes persistentes.

Mas a realidade é essa: cada um com sua forma de pensar. Nas próximas linhas vou definir a minha. Como eu utilizo geradores de código apartir de definições de banco, é importante adotar um comportamento padrão. Vamos lá.

Definições Gerais

1. Evitar abreviações. O nome completo deve ser preferido.
2. Só utilizar letras maiúsculas.
3. O nome das entidades de banco deve ser no sigular.
4. Procurar utilizar nomes que identifiquem sua utilidade e aplicação.
5. Para nomes compostos, separar com underline, por exemplo: RAZAO_SOCIAL.
6. Evitar usar o nome da entidade em seus componentes internos, por exemplo: Se o nome da tabela for PACIENTE, o campo para preenchimento com o nome do paciente será NOME e não NOME_PACIENTE.

Tabelas

Para objetos relacionados com tabelas (chave primaria, chave estrangeira, campos, indices, etc.) vamos adotar o seguinte comportamento:

Chave Primaria

1. Não usar chave primária composta.
2. Deve ser sempre o primeiro campo na tabela e ser formado por “ID_NOME_DA_TABELA”. Para tabela PACIENTE, por exemplo, o champo de chave primária será ID_PACIENTE.
3. O tipo do campo deve ser do tipo numérico mais abrangente possível ( numeric[18,0], bigint ), auto-incremental, com sequence ou generator, se necessário. Não use triggers para auto-incrementar o campo.

índices

1. Deve ser criado sempre; de acordo com as necessidades de ajuste do banco. Normalmente os campos utilizados para ordenação e filtro nas querys precisam de índices.
2. Para os campos que poderiam ter sido escolhidos para chave primária composta, construir o indice com a combinação dos campos utilizando índices marcados como únicos (unique).
3. Deve ser formado por IX_NOME_DA_TABELAn. O ‘n’ no final é apenas um numero sequencial (1,2,3…) para diferenciar os nomes dos índices. Por exemplo: a tabela PACIENTE terá dois índices: IX_PACIENTE1 E IX_PACIENTE2. O primeiro índice pode ter o “1″ opcionalmente. O outros indices (apartir de “2″) são sobrigatórios.

Chaves estrangeiras

1. Na tabela, o nome do campo deve ser igual ao campo chave primária da tabela a que corresponde.
2. Indentificado assim: FK_NOME_DA_TABELA_NOME_DA_TABELA_ESTRANGEIRA. Por exemplo: a tabela PACIENTE possui uma chave estrangeira para tabela SEXO. O nome do campo na tabela PACIENTE deve ser ID_SEXO e o nome da chave estrangerira será FK_PACIENTE_SEXO.

Restrições (constraint)

1. Opcional. Eu evito utilizar. Prefiro utilizar na camada de negócio.

Tipos

1. Respeite o tipo de dado para o campo. Campo data para guardar datas, numéricos para guardar números, etc.
2. Alguns bancos disponibilizam tipos comum com quantidade de bytes reduzidas. Por exemplo: para campo numérico existe: int, smallint, tynint, etc. Procure evitar as variações. Prefira os tipos que são comuns a todos os tipos de bancos. Use os tipos abaixo. Eles costumam ter tamanho bem definido e nome de tipos comuns a todos os bancos.

• Numéricos: int ou integer
• Data: DateTime ou TIMESTAMP
• String: varchar
• Boolean: smallint ou bit
• Campos bynários ou longos: BLOB

SEQUENCE ou GENERATOR

1. Deve ser criada da seguinte forma: GEN_NOME_DA_TABELA_ID. Para a tabela PACIENTE crie um sequence ou generator GEN_PACIENTE_ID.

Visões

1. O nome da view deve ser V$NOME_VIEW ou VNOME_VIEW. Ex: V$PACIENTE_INTERNADO ou VPACIENTE_INTERNADO

Procedures, Functions, Triggers…

Eu evito terminantemente utilizar objetos que possam exigir reescrita caso seja necessário mudar de banco de dados, exceto as views, claro. Inclusive eu escrevi um post sobre “Independência de Banco de Dados”. Leia mais…

É isso. Espero ter ajudado. Quem tiver alguma maneira diferente de entender ou enxergar este assunto, por favor, não deixe de registrar um comentário ou me enviar por email. Desde já obrigado.

Blz!