No mundo do banco de dados, existem algumas coisas que são universalmente aceitas. O aumento da RAM é amplamente benéfico para os sistemas DMBS. A distribuição de dados e arquivos de log no RAID melhora o desempenho.
As convenções de nomenclatura não são uma dessas coisas.
Este é um tópico surpreendentemente polarizador, com os proponentes de várias metodologias firmemente arraigados em suas posições. E muito vocal e apaixonado em sua defesa do mesmo.
Este artigo aprofundará algumas das convenções específicas e os argumentos de ambos os lados, enquanto tenta apresentar uma conclusão razoável para cada ponto.
O Grande Debate sobre a Pluralização
Em sua essência, este é um tópico simples. Por exemplo, qual é a maneira correta de nomear uma tabela que contém informações do cliente em um esquema de banco de dados relacional? É
Customer ou Customers ? Os argumentos de ambos os lados são abundantes.
À primeira vista , é natural pensar em uma coleção de objetos no plural. Um grupo de vários indivíduos ou empresas seria Clientes . Portanto, uma tabela (sendo uma coleção de objetos) deve ser nomeada no plural. Uma linha individual nessa tabela seria um único cliente .
Os princípios de nomenclatura ISO/IEC, embora datados, recomendam nomes de tabelas pluralizados e nomes de colunas singulares.
A maioria das tabelas de sistema do SQL Server usa nomes no plural (sysnotifications , operadores de sistema ), mas isso é inconsistente. Por que sysproxylogin e não sysproxylogins ?
Em argumentos para nomes de tabelas no plural, as linhas em uma tabela também são referenciadas como ‘instâncias’ de um todo – semelhante a itens em uma coleção. Clientes define todo o conjunto; um único cliente é uma instância de Clientes .
Por outro lado, há muitas razões para usar nomes de objetos singulares.
Embora possa haver muitos itens (ou clientes ) em uma tabela, a própria tabela pode ser considerada uma única entidade. caixa de clientes não é “uma caixa de clientes”, mesmo que tenha um grande número de clientes dentro. Além disso, pode haver apenas um item – ou nenhum – dentro da mesa, tornando “clientes” um nome impróprio.
Se você optar por alterar o nome da tabela com base nas variantes de palavras, podem surgir inconsistências rapidamente. Embora muitas palavras sejam diretas (Cliente torna-se Clientes , Produto torna-se Produtos ), outras palavras podem não ser. Neste caso, Pessoa podem se tornar Pessoas ou Pessoas; um Alce singular teria a mesma aparência que sua forma plural, Moose . (Embora por que você precisaria de uma mesa de alce?) Uma convenção como People.FirstName começa a ficar confusamente obscura.
Se vários idiomas estiverem envolvidos, a situação fica ainda pior. Como a pluralização de palavras pode variar de muitas maneiras (clientes, ratos, alces, crianças, crises, syllabi, aeronaves), os falantes não nativos têm desafios adicionais. Ficar com nomes de objetos singulares evita esse problema inteiramente.
A questão da convenção de caso
Não há o mesmo fervor com as convenções de caso quanto com a pluralização, mas os argumentos são feitos para várias opções diferentes. Eles incluem:
- Caixa Pascal :A primeira letra de cada palavra concatenada é maiúscula, como em:
CustomerOrder -
Caixa de camelo :A primeira letra da primeira palavra é minúscula; todas as palavras concatenadas subsequentes têm uma primeira letra maiúscula, como em:customerOrder
O Pascal Case às vezes é considerado um subtipo do Camel Case, mas a Microsoft geralmente diferencia os dois.
Para palavras com menos de três caracteres, é recomendável usar apenas letras maiúsculas, como emUIouIO.
- Sublinhado [Caso “C”] :as palavras são separadas por sublinhados, como em
Customer_Order, oucustomer_Order– ainda mais decisões!
Pesquisadores da Universidade Johns Hopkins realizaram um estudo sobre a eficiência do uso de sublinhados na programação de nomes de objetos. Eles descobriram que o uso do Camel Case (ou Pascal Case) melhorou a precisão e o reconhecimento da digitação. Underscores foram amplamente utilizados em programação C, mas a tendência é para Camel/Pascal Case com ênfase recente em linguagens de estilo Microsoft e Java.
Assim como nos outros tópicos, seguindo uma convenção estabelecida é mais importante que a seleção da própria convenção.
Uma consideração adicional aqui é a diferenciação entre maiúsculas e minúsculas do banco de dados. O agrupamento do SQL Server determina essa sensibilidade com 'CS' (diferencia maiúsculas de minúsculas) ou 'CI' (não diferencia maiúsculas de minúsculas) no nome do agrupamento. Por exemplo:
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
Em agrupamentos que diferenciam maiúsculas de minúsculas,
Select * from myTable falharia no objeto MyTable . Isso pode tornar os sublinhados um pouco preferíveis para evitar confusão, mas o Intellisense também ajuda a eliminar erros de digitação na maioria dos ambientes de programação modernos. Outras considerações sobre convenções de nomenclatura
O Debate Singular versus Plural e a Questão do Grande Caso pode ser onde a batalha é mais feroz, mas há pelo menos mais três áreas a serem consideradas ao considerar uma convenção de nomenclatura.
Evite usar palavras reservadas do SQL Server como nomes de objetos. Isso inclui tabelas e colunas. Por exemplo – Usuário , Hora e Data são reservados. Palavras-chave reservadas podem exigir cuidados adicionais para referência (como o uso de colchetes), dependendo do aplicativo de chamada. Isso também se aplica aos espaços. Espaços em nomes de objetos requerem aspas para referência.
Isso também está relacionado com outra recomendação – precisão. System.CreateDate é muito mais claro que System.Date . Um modelo bem projetado permite que o espectador entenda imediatamente o propósito dos objetos subjacentes. Quando quaisquer identificadores forem referenciados como chaves estrangeiras, seja liberal no nome – Customer.CustomerID em vez de Customer.ID .
Evite prefixos e sufixos para tabelas e visualizações , como
tblTable . A notação húngara (que sempre teve a intenção de identificar o uso de variáveis) caiu nas convenções de nomenclatura comuns do SQL Server, mas é amplamente ridicularizada. Os identificadores de objeto devem descrever o que está contido nele, não o objeto em si. No entanto, prefixos são úteis em objetos de suporte do SQL Server , pois descrevem a natureza funcional do objeto.
Os seguintes são prefixos comumente aceitos para objetos do SQL Server:
- IX:Índice
- PK:chave primária
- FK:chave estrangeira
- CK:verificar restrição
- DF:padrão
- UQ às vezes também é usado para índices exclusivos.
Este modelo ilustra os pontos definidos acima. Não requer explicação quanto à natureza dos dados; convenções de nomenclatura singular são usadas e identificadores claros estão em vigor.
No final, há vantagens e desvantagens para cada lado do debate sobre a nomenclatura da convenção. Há um ponto-chave, no entanto, que ambos os lados podem concordar:independentemente das decisões tomadas, seja consistente com a convenção selecionada.
Quais convenções de nomenclatura SQL você usa e por quê?
