Dilema de nomeação de tabelas: nomes singulares vs. plurais [fechado]

A Academia afirma que os nomes das tabelas devem ser o singular da entidade na qual eles armazenam atributos.

Não gosto de nenhum T-SQL que exija colchetes em torno de nomes, mas renomei uma Userstabela para singular, sempre condenando aqueles que usam a tabela a usar algumas vezes colchetes.

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

Devo ficar ou devo ir?

Outros deram respostas muito boas quanto aos "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 contidos na tabela ? Não que você fique louco demais com nomes e especificidades de tabelas, mas talvez algo como "Widget_Users" (onde "Widget" seja o nome do seu aplicativo ou site) seja mais apropriado.

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

Razão 1 (conceito). Você pode pensar em uma bolsa contendo maçãs como "AppleBag", não importa se contém 0, 1 ou um milhão de maçãs, é sempre a mesma bolsa. As tabelas são apenas isso, contêineres, o nome da tabela deve descrever o que ela contém, não a quantidade de dados que ela contém. Além disso, o conceito plural é mais sobre um idioma falado (na verdade, para determinar se existe um ou mais).

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

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

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

• 1. pedido
• 2.OrderDetail

Comparado com:

• 1.OrderDetails
• 2. pedidos

Razão 4 (Simplicidade). Juntos, nomes de tabelas, chaves primárias, relacionamentos, classes de entidade ... é melhor ter conhecimento de apenas um nome (singular) em vez de dois (classe singular, tabela plural, campo singular, detalhe 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 idioma nativo. 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". Ter nomes singulares pode levar a menos erros causados ​​por erros de digitação, economizando 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é fazer com que o teclado do computador dure mais tempo!

• 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 toques extras no teclado :)

E, finalmente, você pode nomear aqueles que mexem com nomes reservados, como:

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

Ou use os famosos colchetes [Usuário]

Se você usar as ferramentas de mapeamento relacional de objetos ou, no futuro, sugiro o Singular .

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

Minha nova regra geral é julgar como será a aparência depois de convertida em um objeto.

uma tabela que achei que não se encaixa na nova nomeação usada é UsersInRoles. Mas sempre haverá essas poucas exceções e, mesmo nesse caso, parece ótimo como UsersInRoles.Username.

Prefiro usar o substantivo não influenciado , que em inglês é singular.

A inflexão do número do nome da tabela causa problemas ortográficos (como muitas das outras respostas mostram), mas optar por fazê-lo porque as tabelas geralmente contêm várias linhas também está semanticamente cheio de furos. Isso é mais óbvio se considerarmos uma linguagem que flexiona substantivos com base em maiúsculas e minúsculas (como a maioria):

Como geralmente fazemos algo com as linhas, por que não colocar o nome no caso acusativo? Se temos uma tabela na qual escrevemos mais do que lemos, por que não colocar o nome em dativo? É uma mesa de alguma coisa, por que 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. Inflingir o substantivo sem uma razão semântica precisa e absoluta é tagarelar.

O uso do substantivo não influenciado é simples, lógico, regular e independente do idioma.

Que convenção exige que as tabelas tenham nomes singulares? Eu sempre pensei que eram nomes plurais.

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

Este site concorda em:
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: estas são apenas diretrizes. Escolha uma convenção que funcione para você e sua empresa / projeto e atenha-se a ela. Alternar entre singular e plural ou, às vezes, abreviatura de palavras 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 que o anterior.

Eu voto no singular .

Acredito firmemente que, em um diagrama de relação de entidades, a entidade deve ser refletida com um nome singular, semelhante a um nome de classe 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, Usuário é transformado em Usuários da tabela. Concordo com outras pessoas que sugeriram que talvez o nome Usuário pudesse ser aprimorado 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 um grupo de registros e, se o nome da tabela for singular, ele não será bem lido.

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

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

Isso realmente ajuda a pluralidade a se destacar, e posso determinar de maneira fácil e programática como seria a coleção de coisas.

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

IMHO, os nomes das tabelas devem ser no plural, como Clientes .

Os nomes de classe devem ser singulares como Customer se mapear para uma linha na tabela Customers .

Singular. Não compro nenhum argumento envolvendo o que é mais lógico - toda pessoa pensa 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 um idioma 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.

Então, a AppUserrelação diz quais são as entidades AppUsers.

A AppUserGrouprelação me diz quais entidades sãoAppUserGroups

A AppUser_AppUserGrouprelação me diz como AppUserse AppUserGroupsestão relacionados.

A AppUserGroup_AppUserGrouprelação me diz como AppUserGroupse AppUserGroupsestã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 aumentar a legibilidade - depois uso fontes etc. para distinguir o nome da tabela / relação do plural s.

Eu gosto de pensar nisso como confuso, mas sistemático - e, desse modo, sempre existe um nome gerado sistematicamente para a relação que desejo expressar, o que para mim é muito importante.

Eu também usaria os plurais e, com o dilema de usuários mencionado , adotamos 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 de Usuário tanto quanto uma coleção Usuários em um artefato de código é uma coleção de objetos Usuário .

O fato de nossa equipe de dados e nossos desenvolvedores falarem a mesma linguagem conceitual (embora nem sempre tenham os mesmos nomes de objetos) facilita a transmissão de idéias entre eles.

Pessoalmente, prefiro usar nomes plurais 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 ele. Às vezes, você só precisa facilitar a vida de 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:

Gosto das minhas panquecas com mel, não importa qual é o sabor favorito de todos. Mas se eu estiver cozinhando para outras pessoas, tentarei lhes servir o que eles gostam.

Singular. Eu chamaria uma matriz contendo um monte de objetos de representação de linha de usuário 'users', mas a tabela é 'the user table'. Pensar na tabela como nada além do conjunto de linhas que ela contém está errado, IMO; a tabela são os metadados e o conjunto de linhas é hierarquicamente anexado à tabela, não é a própria tabela.

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

Na verdade, sempre achei que era uma convenção popular usar nomes de tabelas plurais. Até este ponto, eu sempre usei o 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 banco de dados normalizado, cada tabela contém conjuntos específicos de dados. Cada linha é uma entidade e a tabela contém muitas entidades. Assim, a forma plural para o nome da tabela.

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

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

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

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ê o torna contável (frango vs galinha; carne vs pássaro). Também não gosto de usar abreviações para o nome da tabela ou o nome da coluna porque isso adiciona uma inclinação extra à curva de aprendizado já íngreme.

Ironicamente, posso abrir Useruma exceção e chamá-la Userspor causa de USER (Transac-SQL) , porque também não gosto de usar colchetes em volta das tabelas se não for necessário.

Também gosto de nomear todas as colunas de identificação como Id, não ChickenIdou ChickensId(o que os caras do plural fazem sobre isso?).

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

Executamos padrões semelhantes, quando o script exigimos [] em torno de nomes e, quando apropriado, qualificadores de esquema - principalmente protege suas apostas contra futuras capturas de nomes pela sintaxe SQL.

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

Isso salvou nossas almas no passado - alguns de nossos sistemas de banco de dados foram executados há mais de 10 anos entre o SQL 6.0 e o SQL 2005 - muito além do tempo de vida útil pretendido.

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 de qualquer maneira.

Sou fã de nomes de tabelas singulares, pois eles facilitam a leitura dos diagramas de ER usando a sintaxe CASE, mas ao ler essas respostas, sinto que nunca percebi muito bem? Eu pessoalmente amo isso. Há uma boa visão geral com exemplos de quão legíveis seus modelos podem ser quando você usa nomes de tabelas singulares, adiciona verbos de ação aos seus relacionamentos e forma boas frases para todos os relacionamentos. É 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 o entenderão sem um bom diagrama legível?

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

Quanto ao prefixo de tabelas e visualizações, eu odeio essa prática. Não dê informações a uma pessoa antes de fornecer informações possivelmente ruins. Qualquer pessoa que esteja navegando em um banco de dados para objetos pode distinguir facilmente uma tabela a partir de uma visualização, mas se eu tiver uma tabela chamada tblUsers, por alguma razão eu decidirei reestruturar no futuro em duas tabelas, com uma visualização unificando-as para não quebrar o código antigo Agora tenho uma visão chamada tblUsers. Nesse ponto, tenho duas opções desagradáveis, deixo uma visualização nomeada com um prefixo tbl que pode confundir alguns desenvolvedores ou forçar outra camada, camada intermediária ou aplicativo, a ser reescrita para fazer referência à minha nova estrutura ou nome de viewUsers. Isso nega uma grande parte do valor das opiniões IMHO.

O sistema tables/viewsdo próprio servidor ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, etc.) são quase sempre plural. Acho que, por uma questão de consistência, eu seguiria a liderança deles.

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

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

Lembro-me na academia, a recomendação era singular.

Por exemplo, quando dizemos:

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

talvez b / c cada um IDseja selecionado em uma única linha específica ...?

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

A menos que você possa padronizar todo o banco de dados, ou pelo menos esteja planejando trabalhar para esse fim, suspeito que os nomes das tabelas sejam apenas a ponta do iceberg e que esteja concentrado na tarefa em questão, suportando a dor de objetos mal nomeados. seu melhor interesse -

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

my2cents ---

Alternativas possíveis:

• Renomeie a tabela SystemUser
• Use colchetes
• Mantenha os nomes das tabelas no plural.

A IMO usando colchetes é tecnicamente a abordagem mais segura, embora seja um pouco complicada. Na IMO, são seis de uma, meia dúzia da outra, e sua solução realmente se resume à preferência pessoal / da equipe.

Minha opinião é sobre 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çãs" ou "maçã".

Exemplo: uma tabela "faculdade" pode conter 0 ou mais faculdades uma tabela de "faculdades" pode conter 0 ou mais faculdades

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

Minha conclusão é que qualquer um está bem, mas você precisa definir como você (ou as pessoas que interagem com ele) se aproximará quando se referir às tabelas; "tabela de machado" ou uma "tabela de xs"

Como outros já mencionaram aqui, as convenções devem ser uma ferramenta para aumentar a facilidade de uso e a legibilidade. Não como um grilhão ou um clube para torturar desenvolvedores.

Dito isto, minha preferência pessoal é usar nomes singulares para tabelas e colunas. Isso provavelmente vem do meu background de programação. Os nomes das classes geralmente são singulares, a menos que sejam algum tipo de coleção. Em minha mente, estou armazenando ou lendo registros individuais na tabela em questão, tão singular faz sentido para mim.

Essa prática também me permite reservar nomes de tabelas plurais para aqueles que armazenam relacionamentos muitos-para-muitos entre meus objetos.

Também tento evitar palavras reservadas nos nomes das minhas tabelas e colunas. No caso em questão, faz mais sentido contrariar a convenção singular para Usuários, para evitar a necessidade de encapsular uma tabela que use a palavra reservada Usuário.

Eu gosto de usar prefixos de maneira limitada (tbl para nomes de tabelas, sp_ para nomes de proc, etc.), embora muitos acreditem que isso acrescente confusão. Também prefiro os nomes do CamelBack a sublinhados, porque sempre acabo pressionando o + em vez de _ ao digitar o nome. Muitos outros discordam.

Aqui está outro bom link para diretrizes de convenção de nomenclatura: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

Lembre-se de que o fator mais importante em sua convenção é que faz sentido para as pessoas que interagem com o banco de dados em questão. Não existe um "anel para governar todos" quando se trata de convenções de nomenclatura.

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

Acho que estou me inclinando a favor do singular no momento por causa de irregularidades plurais 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 de especificação à sua frente (der / die / das). E nas línguas chinesas não há formas plurais de qualquer maneira.

Uma vez eu usei "Cara" na tabela Usuário - o mesmo número curto de caracteres, sem conflito com palavras-chave, ainda uma referência a um ser humano genérico. Se eu não estivesse preocupado com as cabeças abafadas que poderiam ver o código, eu teria mantido dessa maneira.

Eu sempre usei o singular simplesmente porque foi o que me ensinaram. No entanto, ao criar um novo esquema recentemente, pela primeira vez em muito tempo, decidi ativamente manter essa convenção simplesmente porque ... é mais curto. Adicionar um 's' ao final de cada nome de tabela parece tão inútil para mim quanto adicionar 'tbl_' na frente de cada um.

Eu sempre pensei que era uma convenção idiota. Eu uso nomes de tabelas no plural.

(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 objeto e coleção, pois é mais fácil produzir um nome plural a partir de um nome singular do que vice-versa)

Eu só uso substantivos para os nomes das minhas tabelas que estão escritos da mesma forma, sejam eles singulares ou plurais:

alce peixe veado aeronaves você calças shorts óculos tesoura espécies prole

Não vi isso claramente articulado em nenhuma das respostas anteriores. Muitos programadores não têm uma definição formal em mente ao trabalhar com tabelas. Frequentemente, nos comunicamos intuitivamente em termos de "registros" ou "linhas". No entanto, com algumas exceções para relações desnormalizadas, as tabelas geralmente são projetadas para que a relação entre os atributos não-chave e a chave constitua uma função teórica definida.

Uma função pode ser definida como um subconjunto de um produto cruzado entre dois conjuntos, no qual cada elemento do conjunto de chaves ocorre no máximo uma vez no mapeamento. Portanto, a terminologia que surge dessa perspectiva tende a ser singular. Vê-se a mesma convenção singular (ou pelo menos não-plural) em outras teorias matemáticas e computacionais envolvendo funções (álgebra e cálculo lambda, por exemplo).