uma - padrão camelcase sql




Dilema de nomeação de tabelas: nomes singulares versus plurais (20)

Acredito firmemente que, em um Diagrama de Relação de Entidade, a entidade deve ser refletida com um nome singular, semelhante a um nome de classe sendo singular. Uma vez instanciado, o nome reflete sua instância. Portanto, com bancos de dados, a entidade quando transformada em uma tabela (uma coleção de entidades ou registros) é plural. Entidade, o usuário é feito na tabela Usuários. Eu concordaria com outras pessoas que sugeriram que talvez o nome Usuário possa ser melhorado para Funcionário ou algo mais aplicável ao seu cenário.

Isso faz mais sentido em uma instrução SQL porque você está selecionando de um grupo de registros e se o nome da tabela é singular, ele não lê bem.

Academia diz que nomes de tabelas devem ser o singular da entidade que eles armazenam atributos.

Eu não gosto de qualquer T-SQL que requer colchetes em torno de nomes, mas eu renomei uma tabela de Users para o singular, sempre sentenciando aqueles que usam a tabela para, às vezes, usar colchetes.

Meu instinto é que é mais correto ficar com o singular, mas minha intuição é também que os colchetes indicam indesejáveis ​​como nomes de colunas com espaços neles etc.

Devo ficar ou devo ir?


Eu fico com singular para nomes de tabelas e qualquer entidade de programação.

O motivo? O fato de que existem plurais irregulares em Inglês como rato ⇒ camundongos e ovelhas ⇒ ovelhas . Então, se eu precisar de uma coleção , eu apenas uso mouses ou ovelhas , e seguirei em frente.

Realmente ajuda a pluralidade a se destacar, e eu posso facilmente e programaticamente determinar como seria a coleção de coisas.

Então, minha regra é: tudo é singular, toda coleção de coisas é singular com um s acrescentado. Ajuda com ORMs também.


Eu pessoalmente prefiro usar nomes no plural para representar um conjunto, apenas "soa" melhor para minha mente relacional.

Neste exato momento, estou usando nomes singulares para definir um modelo de dados para minha empresa, porque a maioria das pessoas no trabalho se sente mais à vontade com isso. Às vezes você só tem que tornar a vida mais fácil para todos, em vez de impor suas preferências pessoais. (foi assim que acabei neste tópico, para obter uma confirmação sobre qual deveria ser a "melhor prática" para nomear tabelas)

Depois de ler todas as discussões neste tópico, cheguei a uma conclusão:

Eu gosto de minhas panquecas com mel, não importa o sabor favorito de todo mundo. Mas se eu estiver cozinhando para outras pessoas, vou tentar servir-lhes algo que elas gostem.


Eu prefiro usar o substantivo não flexionado , que em inglês é singular.

Infligir o número do nome da tabela causa problemas ortográficos (como muitas das outras respostas mostram), mas escolher fazer isso porque as tabelas geralmente contêm várias linhas também é semanticamente cheio de buracos. Isso é mais óbvio se considerarmos uma linguagem que influencia substantivos com base no caso (como a maioria faz):

Como geralmente estamos fazendo algo com as linhas, por que não colocar o nome no caso acusativo? Se tivermos uma tabela que escrevemos mais do que lemos, por que não colocar o nome em dativo? É uma tabela de algo, porque não usar o genitivo? Não faríamos isso, porque a tabela é definida como um contêiner abstrato que existe independentemente de seu estado ou uso. Infligir o substantivo sem uma razão semântica precisa e absoluta é balbuciar.

Usar o substantivo não-flexionado é simples, lógico, regular e independente de linguagem.


Eu também iria com plurais , e com o dilema de usuários acima mencionado, nós tomamos a abordagem de colchetes.

Fazemos isso para fornecer uniformidade entre a arquitetura do banco de dados e a arquitetura do aplicativo, com o entendimento subjacente de que a tabela Usuários é uma coleção de valores do Usuário , tanto quanto uma coleção Usuários em um artefato de código é uma coleção de objetos Usuário .

Ter nossa equipe de dados e nossos desenvolvedores falando a mesma linguagem conceitual (embora nem sempre os mesmos nomes de objetos) facilitam a transmissão de idéias entre eles.


Eu tive a mesma pergunta, e depois de ler todas as respostas aqui eu definitivamente fico com SINGULAR, razões:

Razão 1 (Conceito). Você pode pensar em saco contendo maçãs como "AppleBag", não importa se contém 0, 1 ou um milhão de maçãs, é sempre o mesmo saco. Tabelas são apenas isso, contêineres, o nome da tabela deve descrever o que ela contém e não quantos dados ela contém. Além disso, o conceito plural é mais sobre um idioma falado (na verdade, para determinar se há um ou mais).

Razão 2 . (Conveniência). é mais fácil sair com nomes singulares do que com nomes no plural. Os objetos podem ter plurais irregulares ou não plurais, mas sempre terão um singular (com poucas exceções, como News).

  • Cliente
  • Ordem
  • Do utilizador
  • Status
  • Notícia

Razão 3 (Estética e Ordem). Especialmente em cenários de detalhes mestres, isso é melhor, alinha melhor pelo nome e tem uma ordem mais lógica (mestre primeiro, detalhe segundo):

  • 1.Order
  • 2.OrderDetail

Comparado com:

  • 1.OrderDetails
  • 2.Orders

Razão 4 (Simplicidade). Colocando tudo junto, Nomes de Tabela, Chaves Primárias, Relacionamentos, Classes de Entidade ... é melhor estar ciente de apenas um nome (singular) ao invés de dois (classe singular, tabela plural, campo singular, singular-mestre singular-plural .. .)

  • Customer
  • Customer.CustomerID
  • CustomerAddress
  • public Class Customer {...}
  • SELECT FROM Customer WHERE CustomerID = 100

Depois que você souber que está lidando com "Cliente", pode ter certeza de que usará a mesma palavra para todas as suas necessidades de interação com o banco de dados.

Razão 5 . (Globalização). O mundo está ficando menor, você pode ter uma equipe de diferentes nacionalidades, nem todo mundo tem o inglês como língua nativa. Seria mais fácil para um programador não-nativo de inglês pensar em "Repositório" do que em "Repositórios" ou "Status" em vez de "Status". Tendo nomes singulares pode levar a menos erros causados ​​por erros de digitação, economizar tempo por não ter que pensar "é criança ou crianças?", Aumentando assim a produtividade.

Razão 6 . (Por que não?). Pode até poupar tempo na escrita, poupar espaço no disco e até tornar o teclado do seu computador mais duradouro!

  • SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
  • SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

Você salvou 3 letras, 3 bytes, 3 acessos extras ao teclado :)

E finalmente, você pode nomear aqueles que estão confusos com nomes reservados como:

  • Usuário> LoginUser, AppUser, SystemUser, CMSUser, ...

Ou use os colchetes infames [Usuário]


IMHO, nomes de tabelas devem ser plurais como os clientes .

Nomes de classes devem ser singulares como Customer se forem mapeados para uma linha na tabela Customers .


Outros deram respostas muito boas no que diz respeito a "padrões", mas eu só queria acrescentar isso ... É possível que "Usuário" (ou "Usuários") não seja realmente uma descrição completa dos dados mantidos na tabela? ? Não que você deva ficar muito louco com nomes de tabelas e especificidade, mas talvez algo como "Widget_Users" (onde "Widget" é o nome do seu aplicativo ou site) seria mais apropriado.


Que tal isso como um exemplo simples:

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

vs.

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

O SQL no último é mais estranho do que o anterior.

Eu voto no singular .


Se você usar ferramentas de Mapeamento Relacional de Objeto ou, no futuro, sugerir Singular .

Algumas ferramentas como LLBLGen podem corrigir automaticamente nomes no plural, como Usuários para Usuário, sem alterar o próprio nome da tabela. Por que isso importa? Porque quando é mapeado você quer que ele se pareça com User.Name em vez de Users.Name ou pior de algumas das minhas tabelas de bancos de dados antigos, nomeando tblUsers.strName, que é apenas confuso no código.

Minha nova regra é avaliar como será a aparência quando for convertida em um objeto.

uma tabela que eu encontrei que não se encaixa na nova nomenclatura que eu uso é UsersInRoles. Mas sempre haverá aquelas poucas exceções e, mesmo nesse caso, parece bem como UsersInRoles.Username.


Singular. Eu não compro qualquer argumento envolvendo o que é mais lógico - cada pessoa acha que sua preferência é mais lógica. Não importa o que você faça, é uma bagunça, basta escolher uma convenção e cumpri-la. Estamos tentando mapear uma linguagem com gramática e semântica altamente irregulares (linguagem falada e escrita normal) para uma gramática altamente regular (SQL) com semântica muito específica.

Meu argumento principal é que não penso nas tabelas como um conjunto, mas como relações.

Portanto, a relação AppUser informa quais entidades são AppUsers .

A relação AppUserGroup informa quais entidades são AppUserGroups

A relação AppUser_AppUserGroup diz-me como os AppUsers e AppUserGroups estão relacionados.

A relação AppUserGroup_AppUserGroup me diz como AppUserGroups e AppUserGroups estão relacionados (ou seja, grupos membros de grupos).

Em outras palavras, quando penso em entidades e como elas estão relacionadas, penso em relações no singular, mas, é claro, quando penso nas entidades em coleções ou conjuntos, as coleções ou conjuntos são plurais.

No meu código, então, e no esquema do banco de dados, eu uso singular. Nas descrições textuais, acabo usando o plural para maior legibilidade - depois, uso de fontes, etc. para distinguir o nome da tabela / relação do plural s.

Gosto de considerá-lo confuso, mas sistemático - e assim sempre há um nome sistematicamente gerado para a relação que desejo expressar, o que para mim é muito importante.


Alternativas possíveis:

  • Renomeie a tabela SystemUser
  • Use parênteses
  • Mantenha os nomes das tabelas no plural.

IMO usando parênteses é tecnicamente a abordagem mais segura, embora seja um pouco incômodo. IMO é 6 de uma, meia dúzia do outro, e sua solução realmente se resume a preferência pessoal / equipe.


Tabelas: plural

Vários usuários estão listados na tabela de usuários.

Modelos: singular

Um usuário singular pode ser selecionado na tabela de usuários.

Controladores: plural

http://myapp.com/users listaria vários usuários.

Essa é a minha opinião sobre isso de qualquer maneira.


A definição de SQL de uma tabela é, na verdade, a definição de uma linha potencial da tabela, não a coleção. Portanto, o nome usado nessa definição deve designar o tipo da linha, não o nome da coleção. As pessoas que preferem o plural porque lêem bem em suas declarações em inglês precisam começar a pensar mais logicamente e examinar toda a lógica e o código de programação envolvidos na utilização real de uma tabela. Existem várias razões muito boas mencionadas nestes comentários para usar nomes de tabelas singulares. Estas incluem boas razões para NÃO usar nomes de tabelas plurais. "Ler bem" não deve ser motivo algum, especialmente porque alguns podem ler a ideia de forma diferente.


Eu acho que usar o singular é o que nos ensinaram na universidade. Mas, ao mesmo tempo, você poderia argumentar que, ao contrário da programação orientada a objetos, uma tabela não é uma instância de seus registros.

Acho que estou dando uma gorjeta em favor do singular no momento por causa das irregularidades no plural em inglês. Em alemão é ainda pior devido a formas plurais consistentes - às vezes você não pode dizer se uma palavra é plural ou não sem o artigo especificando na frente dela (der / die / das). E nas línguas chinesas não há formas plurais de qualquer maneira.


Eu sempre achei que era uma convenção idiota. Eu uso nomes de tabelas plurais.

(Acredito que o racional por trás dessa política é que torna mais fácil para os geradores de código ORM produzir classes de objetos e coleções, já que é mais fácil produzir um nome plural a partir de um nome singular do que vice-versa).


Isso pode ser um pouco redundante, mas eu sugiro ser cauteloso. Não necessariamente que seja algo ruim renomear tabelas, mas a padronização é apenas isso; um padrão - este banco de dados pode já estar "padronizado", por mais que seja ruim :) - Eu sugeriria consistência como um objetivo melhor, dado que esse banco de dados já existe e presumivelmente consiste em mais de apenas duas tabelas.

A menos que você possa padronizar o banco de dados inteiro, ou pelo menos esteja planejando trabalhar nesse sentido, eu suspeito que os nomes das tabelas são apenas a ponta do iceberg e se concentrando na tarefa, suportando a dor de objetos mal nomeados, pode estar em seu melhor interesse -

Consistência prática às vezes é o melhor padrão ... :)

my2cents ---


Minha opinião é na semântica, dependendo de como você define seu contêiner. Por exemplo, um "saco de maçãs" ou simplesmente "maçãs" ou um "saco de maçã" ou "maçã".

Exemplo: uma tabela "universitária" pode conter 0 ou mais colégios. Uma tabela de "faculdades" pode conter 0 ou mais colegas

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

Minha conclusão é que ou é bom, mas você tem que definir como você (ou pessoas interagindo com ele) vão se aproximar quando se referirem às tabelas; "mesa de machados" ou "mesa de xs"


Se olharmos para as MS SQL Server'stabelas do sistema, os nomes deles atribuídos pela Microsoft estão em plural.

As tabelas de sistema do Oracle são nomeadas em singular. Embora alguns deles sejam plurais. A Oracle recomenda plural para nomes de tabelas definidos pelo usuário. Não faz muito sentido que eles recomendem uma coisa e sigam outra. Que os arquitetos desses dois gigantes do software tenham chamado suas tabelas usando diferentes convenções, também não faz muito sentido ... Afinal, quais são esses caras ... PhDs?

Eu me lembro na academia, a recomendação foi singular.

Por exemplo, quando dizemos:

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

talvez b / c cada IDé selecionado de uma única linha particular ...?


Sou fã de nomes de tabelas singulares, pois eles facilitam a leitura dos meus diagramas de ER usando a sintaxe CASE, mas, ao ler essas respostas, tenho a sensação de que nunca se deu muito bem? Eu pessoalmente amo isso. Há uma boa visão geral com exemplos de como seus modelos podem ser legíveis quando você usa nomes de tabelas singulares, adiciona verbos de ação a seus relacionamentos e forma boas frases para todos os relacionamentos. É tudo um pouco exagerado para um banco de dados de 20 tabelas, mas se você tiver um banco de dados com centenas de tabelas e um design complexo, como seus desenvolvedores entenderão isso sem um diagrama legível?

http://www.aisintl.com/case/method.html

Quanto ao prefixo de tabelas e visualizações, eu absolutamente odeio essa prática. Não dê nenhuma informação a nenhuma pessoa antes de dar informações possivelmente ruins. Qualquer um que esteja procurando um banco de dados por objetos pode facilmente dizer uma tabela de uma visão, mas se eu tiver uma tabela chamada tblUsers que por algum motivo eu decido reestruturar no futuro em duas tabelas, com uma visão unificando-as para não quebrar códigos antigos Agora tenho uma visão chamada tblUsers. Neste ponto, fico com duas opções desagradáveis, deixo uma visão nomeada com um prefixo tbl que pode confundir alguns desenvolvedores, ou forço outra camada, seja a camada intermediária ou a aplicação a ser reescrita para referenciar minha nova estrutura ou nomear viewUsers. Isso nega uma grande parte do valor das visualizações IMHO.





naming-conventions