Nomenclatura padrão em SGDB

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”.

“vamorim”:

Pra mim, não tem nada pior que “tbClient_fornecedor2”. :)

Não?

E isso aqui: TBL_001_003_OS

? :?

“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”. :)

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.

“Vegetto”:

“vamorim”:

Pra mim, não tem nada pior que “tbClient_fornecedor2”. :)

Não?

E isso aqui: TBL_001_003_OS

? :?

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

“boaglio”:

Além das dicas já dadas ae, é um bom hábito colocar 2 letras
no nome da coluna para falar o seu datatype.

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

“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

Verdade, eu até não sitei isso pois muitas vezes cada empresa tem seu padrão, mas eu procuro sempre manter assim quando posso.

ID_ = Chave Primaria
NM_ = Nome
CD_ = Códigos
DT_ = Date
FL_ = Flag
DS_ = Descrições
NU_ = Números
Vl_ = Valores
PC_ = Porcentagens

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.

“pcalcado”:

“boaglio”:

Além das dicas já dadas ae, é um bom hábito colocar 2 letras
no nome da coluna para falar o seu datatype.

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

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.

“dsiviotti”:

“pcalcado”:

“boaglio”:

Além das dicas já dadas ae, é um bom hábito colocar 2 letras
no nome da coluna para falar o seu datatype.

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

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.

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