Nome tabella plurale vs singolare

Come devo denominare le mie tabelle durante la creazione di un nuovo database?

Singolare: Cliento plurale: Clients?

Sta a te. Basta essere coerenti però.

Personalmente preferisco singolare in base a ciò che ogni * riga "memorizza: Ordine, Prodotto, Utente, Articolo, ecc.

Questo corrisponde alla mia modellazione (tramite Object Role Modeling) in cui utilizzo entità / tipi singolari.

Modificare:

Una ragione è che il plurale non riesce quando si dispone di tabelle di collegamento:
Orders, Productssarebbe dare OrderProductso OrdersProducts. Nessuno dei due sembra corretto

O tabelle cronologiche (ovviamente puoi usare gli schemi per questo):
Orders-> OrdersHistoryo (no!) OrdersHistories? Non sarebbe Order-> OrderHistorysarebbe meglio?

Per quanto riguarda i nomi delle tabelle singolari rispetto a quelli plurali, l'argomento sembra essere controverso, ma non dovrebbe esserlo.

Mentre una tabella è una raccolta di più record, una tabella prende il nome dalla definizione del tipo di record che contiene. Se a una tabella è stato permesso di avere un nome diverso da quello del tipo di record che contiene, è possibile assegnare alla tabella un nome plurale, in modo da poter ad esempio avere una tabella Employees contenente più record Employee. Ma il progettista di SQL non ha fornito nomi separati per tabelle e tipi di record.

Le cose funzionano in modo più logico per i programmi orientati agli oggetti che usano i dati, se il nome di un tipo di record (e per estensione il nome della tabella) è mantenuto singolare, poiché corrisponderà al nome della classe che useresti per descrivere un record .

Se si desidera quindi identificare una raccolta nel programma, è possibile utilizzare un plurale o, meglio, un modificatore appropriato, come EmployeeList o EmployeeArray.

Esiste anche un problema con i plurali irregolari per la generazione automatica di codice e per i programmatori che hanno background o idee linguistiche diverse sulla formazione dei plurali in un programma.

La lingua inglese non è un linguaggio di programmazione valido e corretto e cercare di rendere le dichiarazioni di database e programmi conformi all'inglese perché suona meglio leggere una di queste affermazioni è un errore.

Proprio come la risposta di @ gbn, penso che questa sia principalmente una questione di preferenze e proprio come lui consiglio a qualsiasi scelta tu abbia fatto di applicarla ovunque (almeno in quel DB). La coerenza ne vale la pena.

La mia preferenza, tuttavia, è che un plurale suona meglio nelle SELECTdichiarazioni:

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

Voglio dire, in questo caso, almeno, ci sono diverse persone nella tabella e molte di esse vengono restituite al client.

"ordine" è una parola riservata. "ordini" non lo è

"utente" è una parola riservata. "utenti" non lo è

"sessione" è una parola riservata. "sessioni" non lo è

"risultato" è una parola riservata. "risultati" non lo è

"relativo" è una parola riservata. "parenti" non lo è

...

Quelle sembrano parole comuni che potrebbero andare nel database line-of-business. Le parole plurali sembrano essere meno comuni come parole chiave rispetto alle parole singole. Pertanto, potrebbe essere utile utilizzare nomi di tabelle plurali in modo da evitare conflitti con le parole chiave SQL.

Credo che la tabella SQL dovrebbe avere nomi plurali. Legge semplicemente molto meglio.

Una tabella di record di libri dovrebbe essere chiamata libri. L'ORM dovrebbe usare la stessa convenzione. L'oggetto Books è una raccolta e presiede tutti i record nella tabella Books. Un oggetto Book presiede un singolo record.

Questo rende la codifica più naturale.

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

Dopo aver lavorato con la programmazione per alcuni anni, ho concluso che la pluralizzazione è una complicazione inutile. La mia opinione è che secondo la filosofia KISS un programmatore dovrebbe cercare la soluzione più pigra e semplice a tutti i problemi per motivi di tempo ed efficienza. Quindi singolare ti dà meno lavoro necessario in tutti gli scenari.

È una cosa molto personale. Uso la forma singolare da 30 anni. Ma capisco perché alla gente piacciono i plurali. I libri - gli autori sono interessanti poiché penso che booksauthors non sia sbagliato. Un libro può avere uno o più autori. E gli autori potrebbero aver scritto uno o più libri (ad es. Co-scritto). Dipende anche da come gestisci i libri scritti da più di un autore. Sono d'accordo con altre risposte; scegline uno e sii coerente. Per quanto riguarda i problemi di parole riservate. Penso che non sia difficile inventare nomi alternativi. utente -> app_user, sessione -> app_session, ordine -> customer_order

Vediamo le cose da diverse prospettive e penso che i due campi siano identificati da:

Singolare ("utente")
La persona che crea una correlazione tra il nome della tabella e il fatto che rappresenti un contenitore, che può contenere più righe.

Quindi "contenitore utente" può contenere più righe.

Plurale ("utenti")
La persona che non fa la correlazione tra il nome della tabella e quel fatto rappresenta un contenitore. Ovviamente sanno che è un contenitore, ma non è presente nel nome.

ad esempio,
un "cartone per uova" può contenere più uova, ma questo è ovvio dato che il riferimento al contenitore è nel nome, fornendo potenziale per più uova. Tuttavia, con il nome della tabella singolare "utente", il riferimento al contenitore non è presente nel nome. ad es. "user_container" sarebbe probabilmente accettabile per le persone che preferiscono nomi plurali.

Penso che ciò sia dovuto anche al fatto che anni di plurale sono una pratica comune e nella maggior parte del materiale didattico online.

Detto questo, penso che tecnicamente parlando il singolare sia più preciso dato che stiamo nominando un singolo contenitore e che i contenitori possono contenere più (o singole) righe.
Sembra sbagliato alle persone in quanto collegano mentalmente il nome della tabella al contenuto (più righe richiedono un nome plurale) piuttosto che collegare mentalmente il contenitore nominato al contenuto (un contenitore consente più).

Come sempre, spesso non c'è un giusto e un sbagliato, ed è più su ciò che si adatta allo scenario, e soprattutto essere coerenti con qualsiasi cosa tu scelga.

Se stai facendo il progetto esclusivamente e non c'è alcun motivo reale per andare in entrambi i modi, fai quello che ritieni sia il migliore, o solo la preferenza. Applica lo stesso quando fai parte di una squadra di sviluppo e prendi una decisione unanime.