Nome da tabela plural vs singular

Como devo nomear minhas tabelas ao criar um novo banco de dados?

Singular: Clientou Plural Clients:?

Você decide. Apenas seja consistente.

Pessoalmente , prefiro o singular com base no que cada * linha "armazena: Pedido, Produto, Usuário, Item, etc.

Isso corresponde à minha modelagem (via Modelagem de Função de Objeto), onde uso entidades / tipos singulares.

Editar:

Uma razão é que plural falha quando você tem tabelas de link:
Orders, Productsdaria OrderProductsou OrdersProducts. Nenhum dos sons está correto

Ou tabelas de histórico (é claro que você pode usar esquemas para isso):
Orders-> OrdersHistoryou (não!) OrdersHistories? Não Order-> OrderHistoryser melhor?

No que diz respeito a nomes de tabelas singulares versus plurais, o assunto parece ser controverso, mas não deveria ser.

Enquanto uma tabela é uma coleção de vários registros, uma tabela é nomeada após a definição do único tipo de registro que ela contém. Se uma tabela tiver um nome diferente daquele do tipo de registro que ela contém, você poderá atribuir à tabela um nome plural, para que você possa, por exemplo, ter uma tabela Employees contendo vários registros Employee. Mas o designer do SQL não forneceu nomes separados para tabelas e tipos de registro.

As coisas funcionam mais logicamente para programas orientados a objetos que usam os dados, se o nome de um tipo de registro (e por extensão o nome da tabela) for mantido singular, pois corresponderá ao nome da classe que você usaria para descrever um registro .

Se você deseja identificar uma coleção no programa, pode usar um plural, ou melhor, um modificador apropriado, como EmployeeList ou EmployeeArray.

Há também um problema com plurais irregulares para geração automática de código e programadores que possuem diferentes origens de linguagem ou idéias sobre a formação de plurais em um programa.

O idioma inglês não é uma linguagem de programação adequada e adequada, e tentar fazer com que as instruções do banco de dados e do programa estejam em conformidade com o inglês porque parece melhor ler uma dessas instruções é um erro.

Assim como a resposta do @ gbn, acho que isso é mais uma questão de preferências e, assim como ele, recomendo que qualquer escolha que você faça, aplique em qualquer lugar (pelo menos nesse banco de dados). Consistência vale a pena.

Minha preferência, no entanto, é que um plural soe melhor nas SELECTdeclarações:

SELECT Id, Name, Status 
FROM   Persons
WHERE  Status <> 5  --5 meaning deleted

Quero dizer, neste caso, pelo menos, há várias pessoas na tabela e várias delas são devolvidas ao cliente.

"ordem" é uma palavra reservada. "pedidos" não é

"usuário" é uma palavra reservada. "usuários" não é

"sessão" é uma palavra reservada. "sessões" não é

"resultado" é uma palavra reservada. "resultados" não é

"relativo" é uma palavra reservada. "parentes" não é

...

Essas parecem palavras comuns que podem estar no banco de dados de linha de negócios. Palavras plurais parecem ser menos comuns como palavras-chave do que palavras singulares. Portanto, pode ser benéfico usar nomes de tabelas plurais para evitar conflitos com palavras-chave SQL.

Acredito que a tabela SQL deve ter nomes no plural. Simplesmente lê muito melhor.

Uma tabela de registros de livros deve ser chamada de livros. O ORM deve usar a mesma convenção. O objeto Books é uma coleção e preside todos os registros na tabela Books. Um objeto Livro preside um único registro.

Isso torna a codificação mais natural.

select name, publication_date from books where publication_date > '2000-01-01';

books = Books()
for book in books.get("publication_date >= '2000-01-01'"):
    print book.name

Depois de trabalhar com programação por alguns anos, concluí que a pluralização é uma complicação desnecessária. Minha opinião é que, de acordo com a filosofia do KISS, um programador deve buscar a solução mais fácil e preguiçosa para todos os problemas por razões de tempo e eficiência. Assim, o singular oferece menos trabalho necessário em todos os cenários.

É uma coisa muito pessoal. Uso a forma singular há 30 anos. Mas posso ver por que as pessoas gostam de plurais. Os livros - autores é interessante, pois acho que os autores de livros não estão errados. Um livro pode ter um ou mais autores. E os autores podem ter escrito um ou mais livros (por exemplo, co-escritos). Também depende apenas de como você lida com livros escritos por mais de um autor. Eu concordo com outras respostas; escolha um e seja consistente. Em relação a questões de palavras reservadas. Eu acho que não é difícil criar nomes de soluções alternativas. usuário -> app_user, sessão -> app_session, pedido -> customer_order

Vemos as coisas de perspectivas diferentes e acho que os dois campos são identificados por:

Singular ("usuário")
A pessoa que faz uma correlação entre o nome da tabela e o fato de representar um contêiner, que pode conter várias linhas.

Portanto, o "contêiner do usuário" pode conter várias linhas.

Plural ("usuários")
A pessoa que não faz a correlação entre o nome da tabela e esse fato que representa um contêiner. É claro que eles sabem que é um contêiner, mas não existe no nome.

por exemplo,
uma "caixa de ovos" pode conter vários ovos, mas isso é óbvio, já que a referência do contêiner está no nome, fornecendo potencial para vários ovos. No entanto, com o nome da tabela singular "usuário", a referência do contêiner não existe no nome. por exemplo, "user_container" provavelmente seria aceitável para pessoas que preferem nomes plurais.

Eu acho que isso também se deve a anos de prática comum no plural e na maioria dos materiais de ensino on-line.

Tudo isso dito, acho que tecnicamente falando o singular é mais preciso, pois estamos nomeando um único contêiner, e os contêineres podem conter várias linhas (ou únicas).
Parece errado para as pessoas, pois elas vinculam mentalmente o nome da tabela ao conteúdo (várias linhas precisam de um nome plural) em vez de vincular mentalmente o contêiner nomeado ao conteúdo (um contêiner permite vários).

Como sempre, embora muitas vezes não haja o certo e o errado, é mais sobre o que se adequa ao cenário e, principalmente, ser consistente com o que você escolher.

Se você está realizando o projeto unicamente e não há motivo real para seguir o caminho, faça o que achar melhor, ou apenas preferência. Aplique o mesmo em uma equipe de desenvolvimento e apenas tome uma decisão unânime.