Nome da tabela plural vs singular

Você decide. Apenas seja consistente embora.

Pessoalmente , prefiro 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 o plural falha quando você tem tabelas de links:
Orders, Productsdaria OrderProductsou OrdersProducts. Nenhum soa correto

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

Com relação a nomes de tabelas no singular versus no plural, o assunto parece ser controverso, mas não deveria ser.

Enquanto uma tabela é uma coleção de vários registros, uma tabela é nomeada de acordo com a definição de um tipo de registro que ela contém. Se uma tabela pudesse ter um nome diferente daquele do tipo de registro que ela contém, você poderia dar à tabela um nome plural, para que você pudesse, 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 no 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, usar 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 têm diferentes origens de linguagem ou ideias sobre a formação de plurais em um programa.

O idioma inglês não é uma linguagem de programação boa 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 soa melhor ler uma dessas instruções é um erro.

"ordem" é uma palavra reservada. "ordens" 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 entrar no banco de dados da 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 no plural para evitar conflitos com palavras-chave SQL.

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-a em todos os lugares (pelo menos nesse banco de dados). A consistência vale a pena.

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

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

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

Depois de alguns anos trabalhando com programação, concluí que a pluralização é uma complicação desnecessária. Minha opinião é que de acordo com a filosofia KISS um programador deve se esforçar para a solução mais preguiçosa e fácil 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.

Acredito que a tabela SQL deve ter nomes no plural. Ele 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 Livros é uma coleção e preside todos os registros na Tabela Livros. Um objeto Book 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

É uma coisa muito pessoal. Eu tenho usado a forma singular por 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 de como você lida com livros escritos por mais de um autor. Concordo com outras respostas; escolha um e seja consistente. Em relação a questões de palavras reservadas. Acho que não é difícil encontrar nomes alternativos. user -> app_user , session -> app_session, pedido -> customer_order

Vemos as coisas de diferentes perspectivas, 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 ela 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 o fato dela representar um container. Claro que eles sabem que é um contêiner, mas não está lá no nome.

Por exemplo
, uma "caixa de ovos" pode conter vários ovos, mas isso é óbvio, pois a referência do recipiente 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 está no nome. por exemplo, "user_container" provavelmente seria aceitável para pessoas que preferem nomes no plural.

Eu acho que isso também é por causa de anos de plural sendo prática comum e na maioria dos materiais didáticos online.

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

Como sempre, muitas vezes não há certo e errado, e é mais sobre o que se adapta ao cenário e, o mais importante, ser consistente com o que você escolher.

Se você está fazendo o projeto apenas e não há nenhuma razão real para ir de qualquer maneira, faça o que achar melhor, ou apenas preferência. Aplique o mesmo quando estiver em uma equipe de desenvolvimento e chegue a uma decisão unânime.

Os argumentos sobre "plural" parecem ser principalmente sobre ser gramaticalmente correto e, embora tenhamos gramática até certo ponto na programação, não é o mesmo que o próprio idioma inglês.

Nomes "plurais" só soam corretos porque as tabelas são consideradas várias coisas, "usuários" etc. Se você estivesse em uma reunião de negócios com 40 dos usuários do seu site, você se referiria a eles como "há todos os nossos usuários ". Mas você não tem "usuários da web" fisicamente em sua tabela, são apenas dados, então pense nisso como "dados de usuário da web". Você não colocaria a palavra "dados" no nome da sua tabela, mas é isso que é, uma coleção de dados com uma ou várias linhas relacionadas a "webUser".

Imagine uma empresa agrícola que precisa armazenar dados sobre seus animais. Eles têm uma mesa chamada "vacas" e devem começar a negociar com "ovelhas".

• A tabela deve ser "ovelha" e quebrar a consistência com todos os outros nomes no plural, como "vacas"?
• A mesa deve ser "ovelha", que é o inglês incorreto? Não é nem uma palavra

O negócio avança ainda mais, e agora eles comercializam veados e bacalhau...

Então, temos inconsistência, o que é irritante para trabalhar:

• vacas
• ovelha
• porcos
• cervo
• bacalhau

Ou consistência, mas com palavras inválidas que levariam a maioria das pessoas a lê-las:

• vacas
• ovelhas
• porcos
• veados
• bacalhau

"bacalhau"? Vamos lá.

Ele também quebra quando você tem várias tabelas que se relacionam com várias palavras. Você continua o plural para consistência e tem nomes de tabelas com sons terríveis, ou quebra a consistência:

• usuários
• usersHolidays ou userHolidays
• usersHolidaysRemainings or userHolidaysRemainings or...????

vs

• do utilizador
• userHoliday
• userHolidayRemaining