Padrão de nomenclatura em bancos de dados: Não Chame de Qualquer Coisa
“É muito interessante notar que muitas empresas (algumas grandes até), ainda não tem um padrão bem definido de nomes de tabelas e atributos em banco de dados.
Ou o padrão que tem não é tão claro. Do ponto de vista de um programador.
Nesse post será mostrado uma experiência com relação a nomenclatura de banco de dados.Não pretendo comparar padrões, e sim mostrar o que EU acho ser interessante. Talvez você já use esse padrão, se não, ou se usa algum outro, vale a pena dar uma conferida mesmo assim, numa dessas você se adapta e programa mais feliz.”
Enviado por Pedro Delfino (pedro·delfino3Θgmail·com) – referência (e-tinet.com).
• Publicado por Augusto Campos em
2009-03-27
@brlinuxblog
Feed RSS
Segue abaixo um programa desenvolvido por um grupo de amigos para tal tarefa, ele foi tema de defesa de TCC. Abraços
http://www.cci.unama.br/margalho/portaltcc/tcc20082s/pdf/fabiola01.pdf
Existia um negócio chamado notação hungara. Provavelmente ainda existe. Acho que é muito popular entre os programadores windows. É uma coisa horrível. =P
Talvez porque as API do windows usam tanto “cast”, e a tipagem das variáveis é uma droga (DWORD!?), a notação hungara era recomendada. Basicamente você colocava no nome da variável várias informações sobre o “tipo” da variável. A questão, é que você exporta para pessoas que não estão nem um pouco interessadas informações totalmente inúteis. Por exemplo, uma aplicação que consulta uma tabela, não está nem um pouco interessada em saber se é de fato uma tabela ou um view! Pra que colocar isso no nome da tabela?
Onde eu trabalho, insistem que campos “seqüênciais” tenham SEQ_ como prefixo. O fato de um “id” ser seqüêncial não interessa a ninguém! Significa simplesmente que o campo tem um valor default. A única informação útil aí, é saber que você não precisa (ou não deve) setar manualmente um valor para este campo. Depois de criada a entrada na tabela, não interessa a ninguém saber que o “id” foi selecionado de acordo com esse ou aquele algorítimo. De fato, se um dia você quiser mudar esse comportamento default, vai sair mudando o nome do campo? Pra quê?
Outra coisa… você vai aproveitar um aplicativo que foi escrito por terceiros. Vai fazer um patch e sair trocando a nomenclatura deles só pra agradar o pessoal da padronização? O que faltou no artigo foi uma reflexão: pra quê padronizar? Cada uma das “orientações” de uma padronização precisa estar muito bem embasada. Padronizar só pra ficar bonitinho é bobagem. Por exemplo, insistir que todos os CPF em um banco de dados tenham exatamente o mesmo “tipo” é uma coisa importante, pois vamos querer fazer o cruzamento dessa informação.
Mais um péssimo exemplo de onde eu trabalho… os caras insistem que toda constraint deve receber um nome e a constraint não pode ficar junto com a definição do campo!! Até as NOT NULL (conseguimos convencê-los, mesmo porque é muuuito inútil dar nome pra isso tudo), REFERENCES, PRIMARY KEY, etc… O que acontece é que fica muito difícil ler as definições totalmente poluídas, e com informações espalhadas. Por exemplo, ao invés de escrever
id_do_sei_la_o_que INTEGER PRIMARY KEY,
id_da_outra_tabela INTEGER NOT NULL REFERENCES outra_tabela,
tenho que escrever
id_do_sei_la_o_que INTEGER,
id_da_outra_tabela INTEGER NOT NULL,
[...]
várias outras coisas
[...]
PRIMARY KEY (id_do_sei_la_o_que),
FOREIGN KEY (id_da_outra_tabela) REFERENCES outra_tabela,
Uma grande burrice! Abaixo à padronização inútil!!
André Caldas.
Acredito que a padronização não seja burrice, mas sim uma forma clara de um programador entender o que outro criou, pois hoje em dia, temos muitos trabalhos desenvolvidos, onde o programador não sabe se ele vai estar a frente daqui a alguns meses, e não é por esse motivo que não podemos deixar algo que fique claro para quem vai nos substituir, a forma como foi nomeado algo, claro que alem de uma boa nomenclatura, segue tambem a documentação de forma correta.
Mas pode ter certeza que o programador que não liga para nomes de bancos ou campos, muito menos ligará para documentar o que está sendo feito.
Para finalizar, sou totalmente de acordo com criação de padroes, da mesma forma que a Sun recomenda padroes para seus codigos java, mas quem gosta segue, quem não gosta não segue (mas tambem não tem um codigo padronizado), da mesma forma é com os bancos de dados.
A grande diferença entre os padrões de desenvolvimento que a SUN usa e os padrões de desenvolvimento de banco de dados é que os da SUN você vê resultado, você entende, percebe que seu trabalho fica bem mais controlado e organizado a qualidade e resultado final melhoram muito sem contar o reuso que aumenta bastante.
Mas os padrões de banco de dados a maioria nem dar para compreender, o mesmo vale para as documentações do RUP, complicam mais do que ajudam, prefiro tocar fogo nos documentos do RUP e usar SCRUM.
Notação húngara só serve para corroer o cérebro. As regras de nomenclatura deveriam ser utilizadas para coisas mais importantes do que tipagem de dados, mesmo porque fazer lambança é fácil:
* NU_CPF INTEGER ou VARCHAR?
* campo SEXO deve ser CHAR(1), INTEGER ou BOOLEAN?
* Qual o padrão para VIEWs e SCHEMAs?
OS DBAs e ADs deveriam preocupar-se com siglas referentes a regras de negócio. Por exemplo, em termos médicos é comum se usar a sigla CID, devido ao Código Internacional de Doenças.
Agora, para saber o tipo dos dados, manda o SQL de criação de banco para o programador, ele saberá exatamente o que fazer, tenho certeza (se não souber, não é programador).
Eu ainda tenho esperanças de que a maioria das pessoas são sensatas e acham que, dentre outras recomendações, sair numerando tabelas, por exemplo, é uma grande bobagem. Se você quer que saibam que a tabela é de cadastro, então ponha a palavra cadastro como um prefixo da tabela!!! E não T001! Não há utilidade nenhuma! Qual é mesmo o nome da tabela de cadastro de usuários? Fácil: T012_Usuario.