Francamente, estou surpreso que, após algumas pesquisas básicas (muito básicas) na Internet, não consegui encontrar uma convenção ou diretriz de nomenclatura abrangente ou nomenclatura de colunas e objetos SQL.
O paralelo a que estou acostumado é no mundo do desenvolvimento .NET, onde existem muitas convenções oferecidas e a Microsoft chegou ao ponto de documentar um conjunto abrangente de recomendações amplamente adotadas:
- Convenções gerais de nomenclatura
- Diretrizes de design para desenvolvimento de biblioteca de classes
- Diretrizes para nomes
1. Existe um padrão bem adotado para objetos de banco de dados, colunas, etc.?
2. Há alguma armadilha em confiar na propriedade Description para descrever as colunas de uma tabela? Obviamente, alguém deseja que o nome revele a intenção, mas às vezes isso é difícil em um banco de dados e as descrições podem ser inestimáveis para alguém que está aprendendo sobre o banco de dados (embora também possam mentir).
Ajuda muito apreciada!
Escolha um padrão, certifique-se de que faz sentido e documente-o. Tem havido muitos debates sobre isso (por exemplo, se a coluna de identidade na tabela de contatos deve ser chamada de ID ou ContactID, ou se a tabela de contatos deve ser chamada dbo.Contacts ou o desnecessariamente detalhado dbo.tblContacts), e você nunca vai encontrar um acordo entre seus pares. Qual padrão você escolhe não é importante; o importante é que você o use consistentemente, torne-o bem conhecido e obtenha o consentimento de seus colegas de que esse é o caminho .
Suas colunas devem ser autodocumentadas (e não enigmáticas, abreviadas ou ofuscadas) sempre que possível. Eu NÃO confiaria nas propriedades estendidas, mas sou apenas eu (google/bing para problemas com propriedades estendidas e você verá muitas reclamações, eu acho). A documentação externa / dicionário de dados é muito mais valioso para mim - se o seu banco de dados for para o sul e o backup também, será muito mais fácil reconstruí-lo. Também torna mais fácil descrever seu esquema para desenvolvedores juniores, etc., sem dar a eles acesso direto a tudo.
Diretrizes de nomeação de elementos de dados ISO/IEC 11179 . Não tenho certeza do que você quer dizer com "bem adotado", mas certamente é abrangente sem ser excessivamente prescritivo. ISO significa que é amplamente adotado.
Minha sugestão: nomeie as coisas com base no que elas fazem ou representam, e não como elas fazem essas coisas. Em outras palavras, não nomeie uma tabela "tblCustomers", ou você pode acabar com uma visão de compatibilidade com versões anteriores chamada "tblCustomers" ou estupidez semelhante. Da mesma forma, não faça isso com nomes de colunas, para não acabar obtendo valores decimais de "fltBalance".
A única exceção é que ocasionalmente prefixarei um nome de exibição com "vw" para deixar claro que é uma exibição, em vez de uma tabela e, portanto, pode haver implicações de desempenho ao buscar dados dela.
Pessoalmente, uso a seguinte convenção para tabelas e exibições: Prefixe o nome da tabela com o tipo de dados que ela contém, o que geralmente é bastante claro, mas nem sempre. Aqui estão alguns exemplos dos prefixos que eu uso:
data_ (Tabelas que contêm dados principais) ref_ (Tabelas de referência que contêm valores de pesquisa) xref_ (Tabelas de junção muitos-para-muitos) info_ (Tabelas de metadados (podem não se aplicar em algumas situações, mas no meu caso, coisas como tabelas que contêm dados sobre quais versões de dados ou aplicativos associados o banco de dados acompanha, etc.)) app_ (Tabelas que são anexadas a outras tabelas por meio de exibições (Mais uma vez, podem não se aplicar a muitas pessoas, mas no meu caso são tabelas estáticas que contêm coisas como informações geográficas, que são anexadas aos registros por coisas como código postal, etc.)
e, é claro, os prefixos fact_ e dim_ amplamente usados para fatos e dimensões em data warehouses.
Pode-se argumentar que tais prefixos devem agora ser implementados como esquemas, mas eu gosto de reservar o esquema para "quem", pois eles fornecem um nível diferente de gerenciamento de segurança.
Onde trabalho atualmente, usamos todas as letras minúsculas para os nomes das colunas e maiúsculas e minúsculas, com separadores de sublinhado para os nomes das tabelas, como: data_Claim_Transactions.
Usamos todas as letras minúsculas para os nomes das colunas, em parte devido ao fato de termos uma mistura de Java e Linux, que diferencia maiúsculas de minúsculas. Além disso, como o Oracle diferencia maiúsculas de minúsculas, acho que mesmo se você estiver usando o SQL Server, que não é o padrão, é uma boa prática projetar para diferenciar maiúsculas de minúsculas. Na verdade, usamos nomes de coluna bastante longos, temos cerca de 100 caracteres, mas são muito descritivos e, dada a natureza do que fazemos, é obrigatório. Eu diria que para um banco de dados de aplicativo, você pode usar nomes de coluna mais curtos. No armazenamento de dados, você tende a precisar de nomes mais longos, especialmente quando possui muitas colunas com conteúdo semelhante ou se possui tabelas altamente desnormalizadas.