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

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 condenando aqueles que usam a tabela para, por vezes, ter que 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?

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.

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 objects 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 (class 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 database.

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é economizar tempo de gravação, economizar espaço em disco e até mesmo 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 accesss 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]

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

Algumas ferramentas como o 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 antigas de bancos de dados, nomeando tblUsers.strName, o que é confuso no código.

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

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

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

Infligir o número do nome da tabela causa problemas ortocharts (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.

Que convenção requer que as tabelas tenham nomes singulares? Eu sempre achei que eram nomes no plural.

Um usuário é adicionado à tabela Usuários.

Este site concorda:
http://vyaskn.tripod.com/object_naming.htm#Tables

Este site não concorda (mas eu discordo):
http://justinsomnia.org/writings/naming_conventions.html


Como outros já mencionaram: são apenas diretrizes. Escolha uma convenção que funcione para você e sua empresa / projeto e mantenha-a. Alternar entre palavras singulares e plurais ou, por vezes, abreviar e, às vezes, não é muito mais agravante.

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 .

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 class sendo singular. Uma vez instanciado, o nome reflete sua instância. Assim, 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.

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, cada coleção de coisas é singular com um s acrescentado. Ajuda com ORMs também.

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 collections ou conjuntos, as collections ou conjuntos são plurais.

No meu código, então, e no esquema do database, eu uso singular. Nas descrições textuais, acabo usando o plural para maior legibilidade – depois, uso de fonts, 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.

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 database 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 objects Usuário .

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

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

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

Singular. Eu chamaria uma matriz contendo um monte de usuários de objects de representação de linha do usuário, mas a tabela é ‘a tabela do usuário’. Pensar na mesa como sendo nada além do conjunto de linhas que ela contém está errado, IMO; a tabela é o metadado e o conjunto de linhas é anexado hierarquicamente à tabela, não é a própria tabela.

Eu uso ORMs o tempo todo, é claro, e ajuda que o código ORM escrito com nomes de tabelas plurais pareça estúpido.

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 não gosto de nomes de tabelas no plural porque alguns substantivos em Inglês não são contáveis ​​(água, sopa, dinheiro) ou o significado muda quando você faz contável (frango vs uma galinha; carne vs ave). Eu também não gosto de usar abreviações para o nome da tabela ou nome da coluna, pois isso adiciona inclinação adicional à curva de aprendizado já íngreme.

Ironicamente, eu poderia tornar o User uma exceção e chamá-lo de Users por causa do USER (Transac-SQL) , porque eu também não gosto de usar colchetes ao redor das tabelas se eu não precisar.

Eu também gosto de nomear todas as colunas de ID como Id , não ChickenId ou ChickensId (o que os caras do plural fazem sobre isso?).

Tudo isso porque não tenho o devido respeito pelos sistemas de database, estou apenas reaplicando o conhecimento de um truque de pônei das convenções de nomenclatura OO, como a falta de hábito e a preguiça do Java . Eu gostaria que houvesse um suporte IDE melhor para SQL complicado.

Executamos padrões semelhantes, quando exigimos scripting [] em torno de nomes e, quando apropriado, qualificadores de esquema – basicamente, ele protege suas apostas contra gripes de nomes futuros pela syntax SQL.

 SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA' 

Isso salvou nossas almas no passado – alguns de nossos sistemas de database foram executados há mais de 10 anos, do SQL 6.0 ao SQL 2005 – muito além do tempo de vida pretendido.

Eu sempre achei que era uma convenção popular usar nomes de tabelas plurais. Até este ponto eu sempre usei plural.

Eu posso entender o argumento para nomes de tabelas singulares, mas para mim o plural faz mais sentido. Um nome de tabela geralmente descreve o que a tabela contém. Em um database normalizado, cada tabela contém conjuntos de dados específicos. Cada linha é uma entidade e a tabela contém muitas entidades. Assim, a forma plural para o nome da tabela.

Uma mesa de carros teria o nome dos carros e cada fileira é um carro. Admito que especificar a tabela junto com o campo de maneira table.field é a melhor prática e que ter nomes de tabelas singulares é mais legível. No entanto, nos dois exemplos seguintes, o primeiro faz mais sentido:

 SELECT * FROM cars WHERE color='blue' SELECT * FROM car WHERE color='blue' 

Honestamente, estarei repensando minha posição sobre o assunto, e confiaria nas convenções atuais usadas pela organização para a qual estou me desenvolvendo. No entanto, acho que para minhas convenções pessoais, vou ficar com nomes de tabelas plurais. Para mim, faz mais sentido.

Eu sou fã de nomes de tabelas singulares, pois eles facilitam a leitura dos meus diagramas de ER usando a syntax CASE, mas ao ler essas respostas, tenho a sensação de que ela nunca foi muito bem recebida. 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 database de 20 tabelas, mas se você tiver um database 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 database por objects 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.

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.

This may be a bit redundant, but I would suggest being cautious. Not necessarily that it’s a bad thing to rename tables, but standardization is just that; a standard — this database may already be “standardized”, however badly 🙂 — I would suggest consistency to be a better goal given that this database already exists and presumably it consists of more than just 2 tables.

Unless you can standardize the entire database, or at least are planning to work towards that end, I suspect that table names are just the tip of the iceberg and concentrating on the task at hand, enduring the pain of poorly named objects, may be in your best interest —

Practical consistency sometimes is the best standard… 🙂

my2cents —

My take is in semantics depending on how you define your container. For example, A “bag of apples” or simply “apples” or an “apple bag” or “apple”.

Example: a “college” table can contain 0 or more colleges a table of “colleges” can contain 0 or more collegues

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

My conclusion is that either is fine but you have to define how you (or people interacting with it) are going to approach when referring to the tables; “ax table” or a “table of xs”

The system tables/views of the server itself ( SYSCAT.TABLES , dbo.sysindexes , ALL_TABLES , information_schema.columns , etc.) are almost always plural. I guess for the sake of consistency I’d follow their lead.

As others have mentioned here, conventions should be a tool for adding to the ease of use and readability. Not as a shackle or a club to torture developers.

That said, my personal preference is to use singular names for both tables and columns. This probably comes from my programming background. Class names are generally singular unless they are some sort of collection. In my mind I am storing or reading individual records in the table in question, so singular makes sense to me.

This practice also allows me to reserve plural table names for those that store many-to-many relationships between my objects.

I try to avoid reserved words in my table and column names, as well. In the case in question here it makes more sense to go counter to the singular convention for Users to avoid the need to encapsulate a table that uses the reserved word of User.

I like using prefixes in a limited manner (tbl for table names, sp_ for proc names, etc), though many believe this adds clutter. I also prefer CamelBack names to underscolors because I always end up hitting the + instead of _ when typing the name. Many others disagree.

Here is another good link for naming convention guidelines: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

Remember that the most important factor in your convention is that it make sense to the people interacting with the database in question. There is no “One Ring to Rule Them All” when it comes to naming conventions.

Possible alternatives:

  • Rename the table SystemUser
  • Use brackets
  • Keep the plural table names.

IMO using brackets is technically the safest approach, though it is a bit cumbersome. IMO it’s 6 of one, half-a-dozen of the other, and your solution really just boils down to personal/team preference.

I think using the singular is what we were taught in university. But at the same time you could argue that unlike in object oriented programming, a table is not an instance of its records.

I think I’m tipping in favour of the singular at the moment because of plural irregularities in English. In German it’s even worse due to no consistent plural forms – sometimes you cannot tell if a word is plural or not without the specifying article in front of it (der/die/das). And in Chinese languages there are no plural forms anyway.

I’ve always used singular simply because that’s what I was taught. However, while creating a new schema recently, for the first time in a long time, I actively decided to maintain this convention simply because… it’s shorter. Adding an ‘s’ to the end of every table name seems as useless to me as adding ‘tbl_’ in front of every one.

I once used “Dude” for the User table – same short number of characters, no conflict with keywords, still a reference to a generic human. If I weren’t concerned about the stuffy heads that might see the code, I would have kept it that way.

If we look at MS SQL Server's system tables, their names as assigned by Microsoft are in plural .

The Oracle’s system tables are named in singular . Although a few of them are plural. Oracle recommends plural for user-defined table names. That doesn’t make much sense that they recommend one thing and follow another. That the architects at these two software giants have named their tables using different conventions, doesn’t make much sense either… After all, what are these guys … PhD’s?

I do remember in academia, the recommendation was singular.

For example, when we say:

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

maybe b/c each ID is selected from a particular single row …?

I only use nouns for my table names that are spelled the same, whether singular or plural:

moose fish deer aircraft you pants shorts eyeglasses scissors species offspring

I always thought that was a dumb convention. I use plural table names.

(I believe the rational behind that policy is that it make it easier for ORM code generators to produce object & collection classs, since it is easier to produce a plural name from a singular name than vice-versa)

The SQL definition of a table is in actuality the definition of one potential row of the table, not the collection. Therefore, the name used in that definition must designate the type of the row, not the name of the collection. People who prefer plural because it reads well in their English statements need to start thinking more logically and look at all of the logic and programming code that is involved with actually using a table. There are several very good reasons mentioned in these comments to use singular table names. These include very good reasons NOT to use plural table names. “Reading well” should not be any reason at all, especially since some may read the idea differently.