Boa tarde
gostaria de saber se existe uma nomenclatura padrão para tabelas e campos no Banco de Dados?
não irei trabalhar com View, Roles e etc… são apenas tabelas e seus respectivos campos. Existe alguma nomenclatura padrão, como o Java possui?
Obrigado
Uma padrãozona para todo mundo usar eu nunca ouvi falar.
As empresas e programadores de qualidade constumam definir seus próprios padrões.
Eu costumo seguir quatro regras simples:
:arrow: Todas as palavras em minúscula, possivelmente separados por anderscor.
:arrow: Todas as palavras em português, ou todas em inglês. Dependendo de quem vai dar manuentenção.
:arrow: E nada de siglas!
:arrow: Evidar números nos nomes
Pra mim, não tem nada pior que “tbClient_fornecedor2”. 
[quote=“vamorim”]
Pra mim, não tem nada pior que “tbClient_fornecedor2”. :)[/quote]
Não?
E isso aqui: TBL_001_003_OS
? :?
[quote=“vamorim”]Uma padrãozona para todo mundo usar eu nunca ouvi falar.
As empresas e programadores de qualidade constumam definir seus próprios padrões.
Eu costumo seguir quatro regras simples:
:arrow: Todas as palavras em minúscula, possivelmente separados por anderscor.
:arrow: Todas as palavras em português, ou todas em inglês. Dependendo de quem vai dar manuentenção.
:arrow: E nada de siglas!
:arrow: Evidar números nos nomes
Pra mim, não tem nada pior que “tbClient_fornecedor2”. :)[/quote]
Concordo com a lista acima e ainda saliento mais um item:
Para uma entidade/tabela chamada CLIENTE, por exemplo, a chave primária (simples) deve se charar ID_CLIENTE. Da mesma forma este campo em outras tabelas como chave estrangeira tem o mesmo nome. Isso padroniza as chaves primárias e facilita visualizar os relacionamentos entre tabelas.
[quote=“Vegetto”][quote=“vamorim”]
Pra mim, não tem nada pior que “tbClient_fornecedor2”. :)[/quote]
Não?
E isso aqui: TBL_001_003_OS
? :?[/quote]
Isso é ADABAS+NATURAL, não é? :lol:
[]s
Olá,
Eu gosto de manter algumas convenções que com o tempo fui vendo em alguns sistemas, juntei o que tinha de melhor 
Table => TB_<NOME_TABELA>
View => VW_<NOME_VIEW>
Colunas de PK => ID_<NOME_COLUNA>
Chaves Primarias => <NOME_ABREVIADO>_PK
Chaves Unicas => <NOME_ABREVIADO>UK
Chaves Estrangeiras => <NOME_ABREVIADO_TABELA_PAI><NOME_ABREVIADO_TABELA_FILHA>_FK
OBS.: Como o dsiviotti já alertou use o mesmo nome de coluna tanto na tabela pai como na filha em uma FK. O sistema que eu trabalho hoje não tem esse padrão e é uma droga de verificar os relacionamentos, pq até os scripts vão por agua a baixo.
Extenções de Arquivos.
Packages:
Header => <NOME_PACKAGE>_PCK.PKS
Body => <NOME_PACKAGE>_PCK.PKB
Procedures => <NOME_PROCEDURE>.PRC
Functions => <NOME_FUNCTION>.FNC
Uso mais alguns para o restanto dos objetos, mas esses ai são os principais e mais usados no dia a dia.
]['s
Além das dicas já dadas ae, é um bom hábito colocar 2 letras
no nome da coluna para falar o seu datatype.
Exemplo:
ao invés de :
clientes.nome
clientes.data_admissao
clientes.salario
assim:
clientes.stnome
clientes.dtadmissao
clientes.nmsalario
Já vi empresas adotarem um padrão para
nome único de coluna para a base inteira.
Algo assim:
clientes.cli_nome
clientes.cli_admissao
clientes.cli_salario
[quote=“boaglio”]Além das dicas já dadas ae, é um bom hábito colocar 2 letras
no nome da coluna para falar o seu datatype.[/quote]
Eu pessoalmente acho isso uma péssima idéia. Se a coluna mudar de tipo de dado, você fica com o nome defasado, fora outros milhares de problemas 
[]s
[quote=“boaglio”]Além das dicas já dadas ae, é um bom hábito colocar 2 letras
no nome da coluna para falar o seu datatype.
Exemplo:
ao invés de :
clientes.nome
clientes.data_admissao
clientes.salario
assim:
clientes.stnome
clientes.dtadmissao
clientes.nmsalario
Já vi empresas adotarem um padrão para
nome único de coluna para a base inteira.
Algo assim:
clientes.cli_nome
clientes.cli_admissao
clientes.cli_salario[/quote]
Verdade, eu até não sitei isso pois muitas vezes cada empresa tem seu padrão, mas eu procuro sempre manter assim quando posso.
[quote]
ID_ = Chave Primaria
NM_ = Nome
CD_ = Códigos
DT_ = Date
FL_ = Flag
DS_ = Descrições
NU_ = Números
Vl_ = Valores
PC_ = Porcentagens[/quote]
Acho que é isso.
]['s
Isso depende muito de projeto. Como estou em um novo projeto, então tivemos que usar a nomeclatura desejada pela Brasil Telecon já que ela é uma de nossas clientes.
[quote=“pcalcado”][quote=“boaglio”]Além das dicas já dadas ae, é um bom hábito colocar 2 letras
no nome da coluna para falar o seu datatype.[/quote]
Eu pessoalmente acho isso uma péssima idéia. Se a coluna mudar de tipo de dado, você fica com o nome defasado, fora outros milhares de problemas
[]s[/quote]
Concordo totalmente. Ainda tem o problema de tipos de dados semelhantes com nomes diferentes de banco para banco. O campo pode ser float, numeric, decimal etc. Nesse caso será um problema. Além do mais, incomoda bastante a leitura, os nomes dos campos ficam enormes. Isso é uma espécie de notação húngara para SQL.
O que às vezes aceito é colocar algo como dt antes de data, mas não é por causa do tipo do campo mas sim por usar dt como abreviação para a palavra Data, assim como Id para Identification ou Identificação. O tipo do campo deve constar da documentação e não no nome do campo.
[quote=“dsiviotti”][quote=“pcalcado”][quote=“boaglio”]Além das dicas já dadas ae, é um bom hábito colocar 2 letras
no nome da coluna para falar o seu datatype.[/quote]
Eu pessoalmente acho isso uma péssima idéia. Se a coluna mudar de tipo de dado, você fica com o nome defasado, fora outros milhares de problemas
[]s[/quote]
Concordo totalmente. Ainda tem o problema de tipos de dados semelhantes com nomes diferentes de banco para banco. O campo pode ser float, numeric, decimal etc. Nesse caso será um problema. Além do mais, incomoda bastante a leitura, os nomes dos campos ficam enormes. Isso é uma espécie de notação húngara para SQL.
O que às vezes aceito é colocar algo como dt antes de data, mas não é por causa do tipo do campo mas sim por usar dt como abreviação para a palavra Data, assim como Id para Identification ou Identificação. O tipo do campo deve constar da documentação e não no nome do campo.[/quote]
Relamente eu também concordo, prefiro ter uma abreviação explicando a informação que a coluna contém e não o tipo de dado dela.
]['s
Prefiro me ater ao simples.
Pessoas
Pessoa_Documentos
Pessoa_Compras
Compras
Compra_Regioes
Compra_FormasPagamento
Sem preposições, obviamente sem acentos e outros caracteres ‘especiais’, abreviações só quando passa dos 25 caracteres, e, como já disseram, manter uma língua só para tudo. Eu prefiro inglês, já que todo o resto é em inglês, mas isso é bem pessoal.
Já ouviram falar em PascalCase e camellCase??? Usar TB_ ou colocar o tipo concatenado com o nome na coluna somente pra quem desenvolve com bloco de notas ou vim…hehehe…
Ex: Tabela
[NomeTabelaPlural] => Usuarios
Ex.: Chave Primária
id (se tem um campo chamado id é óbvio que este vai ser a chave primária)
Ex.: Chave estrangeira
[nomeTabelaSingularId] => usuarioID
Abraços