É muito interessante notar, o quanto muitas empresas (algumas grandes até), ainda não tem um padrão bem definido de nomes de tabelas e atributos. Ou o padrão que tem não é tão claro. E eu estou falando do ponto de vista de um programador.
Nesse post eu quero dividir com vocês a minha (pouca) experiência que eu tenho em 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 
Tabelas: Todas as tabelas começam com a letra T (maiúsculo). Essa foi fácil, é “T” de tabela mesmo.
Após a letra T temos uma sequência numérica 000. Eu prefiro usar três dígitos, em projetos com mais de 999 tabelas, obviamente serão necessários 4 dígitos (ou mais!).
Mas pra que servem os dígitos? Os dígitos servem para identificarmos “o tipo” da tabela. Por exemplo, podemos definir que da tabela T001 à T099, sejam tabelas de cadastro, e que da tabela T100 a T150, sejam de relacionamentos e assim por diante, dependendo das necessidades do projeto.
Após a numeração, teremos um “_” seguido do nome da tabela que começará com a primeira letra maiúscula, por exemplo “T001_Cliente”. Nomes compostos não serão separados por “_”, e todas as primeiras letras serão maiúsculas, por exemplo “T005_UnidadeRemota”.
Analizemos: Em uma outra situação, como identificar se “dependentes” é uma tabela ou um atributo? Teríamos que recorrer a modelagem, ou então abrir nosso gerenciador e conferir, enquanto “T009_Dependentes” por exemplo, fica claro que se trata de uma tabela (pela inicial “T”), que se trata de uma tabela de cadastro (pela convenção supostamente adotada que tabelas de cadastro vão de 001 a 099), e que contém por sua vez o cadastro de dependentes de acordo com o sufixo. Indolor não?
Atributos: Todos os atributos começam com a letra A (maiúscula). “A” de atributo.
Também teremos a sequência numérica 000, mas ela será de acordo com a tabela de origem. Por exemplo: em uma tabela “T001_Clientes”, os atributos seriam: “A001_nome”, “A001_idade”, etc…
Como foi visto no exemplo anterior, os atributos também contém nomes para os identificar, e todos esses nomes serão em minúsculo. Vale a pena usar de bom senso na hora de criarmos os nomes dos atributos, pois o ideal é que sejam nomes curtos (eu gosto de usar nomes com 4 a 8 caracteres), desde que o programador que vá usar entenda o que significa 
Olha aí a grande sacada!
E quando usamos chave estrangeira, como fica?
Essa é a parte mais legal, olha só.
Vamos imaginar uma tabela de endereço – T010_Enderecos. E que nessa tabela contém uma chave primária (!) – A010_codend. Agora vamos voltar a nossa T001_Clientes. Ela contém os atributos:
A001_codcli
A001_nome
A001_idade
A010_codend
Êpa! O que que esse A010_codend está fazendo na minha tabela de clientes???
Essa é a minha chave estrangeira da tabela T010_Enderecos, e é facilmente identificada através do prefixo A010!
Com essa pequena sugestão, a vida do programador se tornará muito mais fácil!
Não vou entrar no mérito de índices, triggers, procedures (a não ser que peçam né), mas é só adotarem a mesma “idéia”, que tudo ficará mais simples.
Os programadores que entrarem “no meio” do projeto, iram te agradecer.
Então é isso, meu nome é Julio Cesar, mas vocês podem me chamar de Jota, como o Pedro disse em minha apresentação. Não pretendo postar com tanta frequência, e também não quero causar tanto “rebuliço” aqui no blog.
Comentem sobre padrões vocês também!
Abraço a todos!
Tem um problema nisso, e as “rolenames” de colunas entre as tabelas? Ficam com que nome?
Por exemplo dois relacionamentos com a mesma tabela, qual a numeração?
Isso é só uma parte da coisa. Padrão de nomenclatura de BD é muito mais do que isso.
Nome de sequence? Procedire? trigger? Databafile, Segmentos? Chaves (ppk e fk)? ìndices únicos? Defaults?
O problema é mais fundo nesse caso.
[Responder]
Não curti… nome com números começa a ficar ilegível. eu uso pra tabelas
[contexto][T ser for tabela, R se for de relacionamento][Nome] ex: personTAddress e
pra attributos uso o nome limpo, para primary keys usu NomeDaTabel[Id] ex: AddressId
acho q fica mais limpo…
[Responder]
uia, nesse caso você vai diferenciar os atributos através do sufixo (nome que aparece depois). Mas ambos terão o mesmo prefixo de acordo com a tabela da fk.
Concordo que isso é só uma parte, é por isso que eu escrevi também: “Não vou entrar no mérito de índices, triggers, procedures (a não ser que peçam né), mas é só adotarem a mesma “idéia”, que tudo ficará mais simples.”
Guismo, isso é só uma idéia baseada em empresas que eu já trabalhei, eu particularmente acho o seu exemplo menos claro… mas isso vai de cada um.
Obrigado pela participação.
[Responder]
E pq não dar nomes que façam sentido só?
Tipo, tabela que guarda informações de clientes? CLIENTE
Procedure que atualiza a situação fiscal de um cliente? UPDATE_SITUACAO_FISCAL_CLIENTE
Fk de Cliente para Pessoa? FK_CodCliente_CodPessoa
O que falta hj em dia para uma boa parte dos programadores é eles verem que o código deve ajudar ele a finalizar o produto.
[Responder]
…ou você começa a usar um ORM e pára de se preocupar com nomeclatura de banco, de ter que se preocupar com a estrutura da tabela porque escreve queries manualmente, e etc.
Particularmente, prefiro usar semântica ao invés de prefixos numéricos e coisas do tipo, que não são nada intuitivos. Mas tudo depende de quem precisa usar esse banco e de como o sistema que o consome é feito.
[Responder]
Concordo com o Limão…
Uma tabela para armazenar dados sobre clientes? Cliente
Uma tabela para armazenar notas fiscais? NotaFiscal
e por ai vai…
Quanto a procedures, updateCliente (…), addNotaFiscal(…)…
Mas em relação aos triggers, concordo em por alguma identificação com mais semântica… insertClienteT(), insertNotaT()
Acho que não ficou claro o por que dessa nomeclatura que você expôs…
[Responder]
Falou tudo Henrique! É por isso que eu gosto do Rails…rs
Limão e PEdroArthur_JEdi, valeu pela participação. Mas prestem atenção nesse trecho que eu escrevi: “…como identificar se “dependentes” é uma tabela ou um atributo? Teríamos que recorrer a modelagem, ou então abrir nosso gerenciador e conferir, enquanto “T009_Dependentes” por exemplo, fica claro que se trata de uma tabela (pela inicial “T”), que se trata de uma tabela de cadastro (pela convenção supostamente adotada que tabelas de cadastro vão de 001 a 099), e que contém por sua vez o cadastro de dependentes de acordo com o sufixo…”
Mais ou menos isso…
Mas vale lembrar q é só uma sugestão galera… Cada um usa o que achar melhor!
[Responder]
Douglas Reply:
fevereiro 8th, 2010 at 18:00
@Jot@!!!, Não sei porque tanto reboliço no post do Jot@, ele colocou algo bem interessante. é mais profundo doque um simples nome de tabela. Eu não uso esse tipo de nomenclatura no projeto, pois peguei no meio, mais se fosse de inicil teria sido bem mais facil, aliáz esses p´refixos dele funciona simplismente como um mapa. Fico pensando como isso teria me poupado tanto trabalho com “firebug” pra descobrir onde tá determinado objeto, ou de onde ele vem…. valeu Jot@
[Responder]
Achei interessante o seu ponto de vista. A idéia é válida desde que seja feito um arquivo de ajuda explicativo, conforme você mesmo descreveu aqui no blog para que outros programadores não fiquem perdidos.
Vou adotar a sua idéia nos meu próximos projetos
Um Abraço
[Responder]
PEdroArthur_JEdi : concordo com vc amigo, a maneira mais tranquila é como fazemos aqui na empresa e se parece com a sua: tabela clientes? clients (utilizamos ingles, pq vc ja programa em ingles, pra q fazer coisas em portugues no meio disso tudo?), revendedores é resellers e assim vai.
Atributos? código é ID, nome é name – sem nomes alienigenas, assim fica legível até pro cliente desde que entenda ingles. Mas mesmo que vc queria em portugues, codigo, nome, endereco e assim vai. Essa coisa de prefixo só atrapalha, cli_nome, cli_endereco, affffff (aff pq já usei assim hehehehe).
Quanto a JOINs, vc apenas coloca o alias, não é nenhum problema, até porque se vc usa um ORM ele vai utilizar o nome das tabelas sempre em qualquer consulta, até é uma boa prática fazer o mesmo.
Quanto a nome de funcao, pk, fk, daí dá pra usar alguma coisa mas mais simples né!
um abração amigos, e acompanhem meu blog, tem uns posts legais de vez em qdo!
[Responder]
Sou Técnico de Informática de empresa estatal. Desde 99, uso o seguinte padrão que aprendi aqui na empresa e fiz algumas modificações:
Peguemos 4 tabelas: EMPREGADO, GERENCIA, DEPENDENTE e GRAU DE PARENTESCO. As colunas ficariam assim: EMPREGADO (EMPR_NR_MATRICULA, EMPR_NM_NOME, EMPR_DT_ADMISSAO, GERE_ID_GERENCIA), GERENCIA (GERE_ID_GERENCIA, GERE_NM_GERENCIA), DEPENDENTE (EMPR_NR_MATRICULA, DEPE_NR_DEPENDENTE, DEPE_NM_DEPENDENTE, DEPE_DT_NASCIMENTO, GRPA_ID_GRAU_PARENTESCO) e GRAU_PARENTESCO (GRPA_ID_GRAU_PARENTESCO, GRPA_TX_DESCRICAO)… Daí, ao olhar tais tabelas, concluo que:
1) As 4 primeiras letras do nome do campo são o “mnemônico” da tabela onde se originam. Se o campo for chave estrangeira, traz o mnemônico da tabela de origem;
2) as 2 letras intermediárias no nome me dizem o tipo de informação que, na maioria das vezes, coinicide com o tipo de dado a grosso modo, do campo;
3) … o restante do nome do campo é o nome do campo propriamente dito.
… assim, se alguém ler na tabela de EMPREGADO o campo GERE_ID_GERENCIA vai concluir que o campo é uma chave estrangeira pois seu mnemônico é diferente de EMPR e que tal campo pertence a uma tabela cujo nome começa com GERE… daí, fica fácil concluir que é IDentificador de gerência. Já o campo EMPR_DT_ADMISSAO me informa que é da tabela EMPRegado e é uma informação tipo DATA (DT). Isso tem me ajudado bastante ao fazer modelagens de bancos de dados que possuem muitas tabelas. Se o nome da tabela for de 2 palavras, uso as duas 1as letras de cada palavra. Exemplo: TIDA_TX_DESCRICAO -> é da tabela TIPO_DADO, informação tipo TEXTO (TX) e o campo é uma DESCRIÇÃO.
Pra fechar, uso os seguintes códigos para tipo de informação no nome do campo: CD (código), DT (data), MD (média), NM (nome), NR (número), QT (quantidade), TP (tipo), TX (texto), VL (valor) e assim poupo usar tais palavras extensivamente no nome dos campos. Não haverá, por exemplo, nos meus bancos de dados campos com os seguintes nomes: EMPR_NR_VALOR_SALARIO e sim EMPR_VL_SALARIO; EMPR_TX_NOME_MAE e sim EMPR_NM_MAE etc…
[Responder]
Ahh esqueci de dizer, parabéns pela iniciativa do POST, mesmo que eu não utilize assim (e confesso que odiaria pegar um banco assim hehehe) achei muito interessante e didático!
PARABÉNS!
[Responder]
Hahah Obrigado pela sinceridade Marco. Mas a sua idéia cai naquela questão que eu já disse no meu comentário antes desse.
)
O importante é nós utilizarmos o melhor pra gente. Essa só foi uma das idéias possíveis. Que bom que gostou Omar!
Eu por exemplo não gostei do método do Paulo (obrigado mesmo assim pela grande participação). Mas tudo vai de uma adaptação também.
Eu trabalhava em uma empresa que tinha uma nomenclatura, que na minha opinião era horrível, mas todos gostavam. Na empresa que eu trabalho eles adotaram essa idéia com algumas modificações. Ou seja, é aquela velha história, gosto é q nem bunda, cada um tm o seu
[Responder]
Para atributos, acho mais fácil identificar usando um prefixo com a inicial ou abreviação do nome da tabela + “_”. Por exemplo: na tabela Cliente, um atributo poderia ser cli_dependentes ou apenas c_dependentes (é claro que usar a inicial só vale se não houver outras tabelas com a mesma inicial, por isso não é muito prático).
[Responder]
Galera …
Legal está discussão: O mais importante na minha opinião é ter um padrão, padrão é tudo.
Quando você inicia um projeto novo, porque não padronizar, fica tudo mais fácil, este exemplo do post pode melhorar muito a vida dos programadores.
Houve um comentário do Henrique, sobre utilizar ORM, (Mapeamento de Objeto Relacional), para não se preocupar, pois o SELECTs podem ser feitos de forma abstraída, eu concordo plenamente, o Ruby on Rails (com o activerecord ) faz isto (e muito mais), agiliza muito a nossa vida, não precisar mais pensar em forkey, isto não tem preço.
Foi motivo de post este assunto: http://www.e-tinet.com/ruby-on-rails/porque-nao-deve-usar-ruby-on-rails-primeiro-motivo/
Na minha opinião, quando não podemos utilizar um padrão de ORM (Mapeamento de Objeto Relacional), o padrão proposto no post, pode ajudar e muito.
valeu … parabéns Jot@, sua participação no e-tinet.com, é sempre bem vinda.
[Responder]
De boa, bizarro…
[Responder]
Já vi vários padrões para nomear tabelas e atributos, mas esse é de longe o pior deles, não usaria de jeito nenhum.
[Responder]
Falou Julio,
Eu particulamente acho interessante a proposta de nomenclatura de relações em Banco.
No início pode parecer um pouco complicado, mas após o período de adaptação você não lê mais “T001_Clientes” mas sim “Tabela de Clientes”.
Mto bom.
[Responder]
Nossa, achei isso muito complicado.
Eu sou um dos defensores que o nome da tabela deve conter somente o que ela armazera. As ferramenta de banco de dados já faz a separação de tabelas / views / sequences de graça, sem precisar de nenhum prefixo.
Acredito que a melhor maneira de organizar o banco não é com prefixos, mas com schemas e descrições.
[Responder]
Jota,
Achei o padrão que você comentou muito interessante!
Se puder detalhe todos além acredito que ficará muito claro para a galera ver…
trabalhamos com um padrão que lembra o seu mas mistura número e letras que nos da uma dimensão da hierarquia das tabelas dentro do sistema.
Esses padrões com números não são bom e nunca serão bem visto para quem trabalha com menos de 100 tabelas, mas se passar disso verá o quanto é bom não ter que ficar vendo os modelos ER para ver quem se relaciona com quem.
Parabéns pelo post espero que possa complementá-lo e que as discursão não parem pessoal…
Até mais…
[Responder]
Para ser sincero achei meio confuso também. Os prefixos numerados realmente atrapalham um pouco.
Além do que, isso gera um problema mais prático: imagine um banco onde temos 99 tabelas de cadastro (que ocupam todos os prefixos separados para tabelas desse tipo). Quando for necessário criar a 100ª tabela, o que faremos? Ampliaremos a numeração? E as outras tabelas do sistema, vai renomear tudo? É muito difícil (eu diria até impossível) estimar com precisão o número de tabelas que um sistema vai ter até sua “morte”.
Na *minha opinião* (não quer dizer que seja a melhor sobre o assunto) a nomenclatura deve ser o mais natural possível. De que adianta uma nomenclatura que complica o entendimento do schema, por melhor que ela seja? Sim, complica porque você precisa de documentação para entender não só o sistema, mas também a nomenclatura. =/
Acho que sempre vale a velha lembrança do KISS – Keep It Simple, Stupid
http://en.wikipedia.org/wiki/KISS_principle
[Responder]
Porque a tabela de pessoas não pode chamar-se somente de “Pessoa” e o campo nome de “nome”? Seria mais fácil de escrever o SQL:
SELECT p.nome, p.cpf, p.dataNascimento
FROM Sistema.Pessoa p
WHERE p.nome LIKE ‘João%’
em vez de
SELECT T1TX_NOME, T1NU_CPF, T1DT_NASC
FROM SC1_SIST.T1_PESSOA
WHERE T1TX_NOME LIKE ‘João%’
PS: Sistema e SC1_SIST são esquemas, ao menos no PgSQL.
[Responder]
Cara, horrível esse padrão de nomeação. Como usamos muito em orientação a objetos, os nomes devem fazer sentido, ter um significado. Compare, é melhor “T001_Clientes” ou simplesmente “Cliente”? A segunda opção é muito mais clara, objetiva e enxuta.
[Responder]
Dê uma olhada nisso aqui: http://www.urubatan.com.br/curso-basico-de-refactoring-para-quem-e-pobre-e-preguicoso/
[Responder]
Ptz… e olha que eu não queria ser polêmico heim…rs
)
Bom, vamos por partes.
Antes de mais nada, eu queria dizer que esse padrão apresentado, não foi inventado por mim. Eu o conheci através de estudos na área e através de uma empresa que eu trabalhei.
Assim como a maioria de vocês, eu tive a mesma reação quando o vi pela primeira vez: “Q p#%%@ é essa???”…rs. Isso é normal. Eu pensei que nunca iria me acostumar, mas me surpreendi ao ver como foi fácil me adaptar.
Douglas, usar um prefixo com a abreviação do nome da tabela pode te complicar quando o nome da tabela é composto, e grande, você pode acabar tendo um prefixo ilegível.
Jose Arthur e João Paulo, respeito a opinião de vocês, mas é como eu já disse e repito: “Em uma outra situação, como identificar se “dependentes” é uma tabela ou um atributo? Teríamos que recorrer a modelagem, ou então abrir nosso gerenciador e conferir, enquanto “T009_Dependentes” por exemplo, fica claro que se trata de uma tabela (pela inicial “T”), que se trata de uma tabela de cadastro (pela convenção supostamente adotada que tabelas de cadastro vão de 001 a 099), e que contém por sua vez o cadastro de dependentes de acordo com o sufixo.”.
Anderson Rodrigo, é exatamente isso cara. Na verdade foi fácil pra você visualizar o que eu estou tentando passar, porque você já trabalha com um padrão parecido. Do contrário, acho normal o espanto…rs
ejedelmal, nossa cara, você “zuou” também né… Quando que eu falei nisso? “SELECT T1TX_NOME, T1NU_CPF, T1DT_NASC
FROM SC1_SIST.T1_PESSOA
WHERE T1TX_NOME LIKE ‘João%’”, c tá loco, se fosse assim nem eu…rs
Mesmo assim pessoal eu agradeço todos os comentários, e quero deixar claro mais uma vez que isso é só uma sugestão. Eu particularmente prefiro usar o Rails que controla tudo isso pra mim
Abraço a todos, até ao senhor bizarro Alan (!).
[Responder]
Ah, já ia me esquecendo…
Anderson Rodrigo, é claro que não devemos deixar a “faixa numérica”, reservada para as tabelas de cadastro, por exemplo, para todas as tabelas iniciais de cadastro. Pois obviamente, como você mesmo disse, essas tabelas poderão aumentar no futuro.
Agora, se mesmo você deixando uma “folga” na numeração ainda sim precisar fazer toda essa realocação que você disse, que eu concordo ser inviável, tá na hora de você rever seus conceitos na fase de análise…
[Responder]
Apenas acho que nomenclatura para definir tipos um uso muito pobre. A notação húngara foi abolida até na MSFT (vide .NET). Agora há usos interessantíssimos de siglas e padrões de nomenclatura associados a dicionário de dados e a regras de negócio.
[Responder]
Tu só pode estar de sacanagem!!! Pq não coloca o Mac Adress da placa de rede no servidor na nomenclatura das tabelas???? Em meu ver a nomenclatura tem que ser objetiva e clara. Utilizo o nome da tabela no plural com PascalCase. Ex.: UsuariosContatos.
Forte abraço.
[Responder]
Jot@ Reply:
setembro 1st, 2009 at 09:39
@Miguel B Brasil,
Olá Miguel, obrigado por participar e, eu não estou de sacanagem não…rs
Esse padrão (pra quem não está acostumado), só deve ser usado pra bancos realmente grandes. Se você tem poucas tabelas, “não compensa” o esforço.
Aqui na empresa onde trabalho, sugeri esse padrão (que como já disse usava em outra empresa), e devido ao grande número de tabelas, projetos, e programadores atuando em sistemas diferentes, foi aceito por todos, pois agora, a convenção é a mesma em todas as bases. Por exemplo, no sistema ‘A’, sabemos que as tabelas (‘T’) com faixa numérica de tanto a tanto são para cadastro. Mudando para o sistema ‘B’ também!
Sei que o padrão parece estranho, e como eu já disse, a primeira vez que olhei para uma base assim pensei: “Por que a tabela de cliente não se chama apenas ‘Clientes’?”. Mas com uma base grande, e depois do (por incrível que pareça, breve) período de adaptação, você vai querer usar esse padrão até com bases pequenas.
Pelo menos comigo e com quem eu conheço foi assim… :~)
Mas essa é apenas uma sugestão. É lógico que cada um usa o que quiser…
Abraço.
[Responder]
Cara excelente a sua padronização, isso tudo é questão de gosto, estava atrás de um padrão para utilizar(porque acredito que nomes simples, CLIENTE por exemplo, deixam todo o banco muito solto e desorganizado, assim como nomes complexos…minha opnião), achei o seu e já estou testando aqui, pra ver se “cola”…parabéns pela iniciativa Jot@!
[Responder]
Não sei porque tanto reboliço no post do Jot@, ele colocou algo bem interessante. é mais profundo doque um simples nome de tabela. Eu não uso esse tipo de nomenclatura no projeto, pois peguei no meio, mais se fosse de inicil teria sido bem mais facil, aliáz esses p´refixos dele funciona simplismente como um mapa. Fico pensando como isso teria me poupado tanto trabalho com “firebug” pra descobrir onde tá determinado objeto, ou de onde ele vem…. valeu Jot@!!!,
[Responder]
Não sei porque tanto reboliço no post do Jot@, ele colocou algo bem interessante. é mais profundo doque um simples nome de tabela. Eu não uso esse tipo de nomenclatura no projeto, pois peguei no meio, mais se fosse de inicil teria sido bem mais facil, aliáz esses p´refixos dele funciona simplismente como um mapa. Fico pensando como isso teria me poupado tanto trabalho com “firebug” pra descobrir onde tá determinado objeto, ou de onde ele vem…. valeu Jot@!
[Responder]