Dilemma di denominazione delle tabelle: nomi singolari e plurali [chiuso]

Secondo il mondo accademico, i nomi delle tabelle dovrebbero essere il singolare dell'entità di cui memorizzano gli attributi.

Non mi piace qualsiasi T-SQL che richiede parentesi quadre attorno ai nomi, ma ho rinominato una Userstabella in singolare, condannando per sempre coloro che usano la tabella a volte devono usare parentesi.

La mia sensazione è che sia più corretto stare con il singolare, ma la mia sensazione è anche che le parentesi indicano indesiderabili come nomi di colonne con spazi in esse ecc.

Dovrei restare o dovrei andare?

Altri hanno dato risposte abbastanza buone per quanto riguarda gli "standard", ma volevo solo aggiungere questo ... È possibile che "Utente" (o "Utenti") non sia in realtà una descrizione completa dei dati contenuti nella tabella ? Non che dovresti impazzire troppo con i nomi delle tabelle e la specificità, ma forse qualcosa come "Widget_Users" (dove "Widget" è il nome della tua applicazione o del tuo sito Web) sarebbe più appropriato.

Ho avuto la stessa domanda, e dopo aver letto tutte le risposte qui rimango sicuramente con SINGULAR, ragioni:

Motivo 1 (concetto). Puoi pensare a un sacchetto contenente mele come "AppleBag", non importa se contiene 0, 1 o un milione di mele, è sempre lo stesso sacchetto. Le tabelle sono solo questo, i contenitori, il nome della tabella deve descrivere ciò che contiene, non quanti dati contiene. Inoltre, il concetto plurale riguarda più una lingua parlata (in realtà per determinare se ne esiste una o più).

Motivo 2 . (Convenienza). è più facile venire fuori con nomi singolari, piuttosto che con nomi plurali. Gli oggetti possono avere plurali irregolari o non essere affatto plurali, ma ne avranno sempre uno singolare (con poche eccezioni come Notizie).

• Cliente
• Ordine
• Utente
• Stato
• notizia

Motivo 3 . (Estetica e Ordine). Soprattutto negli scenari di dettaglio principale, questo si legge meglio, si allinea meglio per nome e ha un ordine più logico (Master prima, Dettaglio secondi):

• 1.Order
• 2.OrderDetail

Rispetto a:

• 1.OrderDetails
• 2.Orders

Motivo 4 (Semplicità). Metti tutti insieme, nomi di tabella, chiavi primarie, relazioni, classi di entità ... è meglio essere consapevoli di un solo nome (singolare) invece di due (classe singolare, tabella plurale, campo singolare, dettaglio principale singolare-plurale .. .)

• Customer
• Customer.CustomerID
• CustomerAddress
• public Class Customer {...}
• SELECT FROM Customer WHERE CustomerID = 100

Una volta che sai di avere a che fare con "Cliente", puoi essere sicuro di usare la stessa parola per tutte le esigenze di interazione del database.

Motivo 5 . (Globalizzazione). Il mondo sta diventando più piccolo, potresti avere un team di diverse nazionalità, non tutti hanno l'inglese come lingua madre. Sarebbe più facile per un programmatore di madrelingua inglese pensare a "Repository" piuttosto che a "Repository", o "Status" anziché "Status". Avere nomi singolari può portare a un minor numero di errori causati da errori di battitura, risparmiare tempo non dovendo pensare "è Child o Children?", Migliorando quindi la produttività.

Motivo 6 . (Perchè no?). Può anche farti risparmiare tempo in scrittura, risparmiare spazio su disco e persino prolungare la durata della tastiera del tuo computer!

• SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
• SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

Hai salvato 3 lettere, 3 byte, 3 ulteriori hit da tastiera :)

E infine, puoi nominare quelli che si incasinano con nomi riservati come:

• Utente> LoginUser, AppUser, SystemUser, CMSUerer, ...

Oppure usa le famigerate parentesi quadre [Utente]

Se usi gli strumenti di mappatura relazionale degli oggetti o lo farò in futuro ti suggerisco Singolare .

Alcuni strumenti come LLBLGen possono correggere automaticamente nomi plurali come Users to User senza cambiare il nome della tabella stessa. Perché è importante? Perché quando è mappato, vuoi che assomigli a User.Name anziché a Users.Name o peggio da alcune delle mie vecchie tabelle di database che nominano tblUsers.strName che è solo confuso nel codice.

La mia nuova regola empirica è giudicare come apparirà una volta che è stato convertito in un oggetto.

una tabella che ho trovato che non si adatta alla nuova denominazione che uso è UsersInRoles. Ma ci saranno sempre quelle poche eccezioni e anche in questo caso sembra UserInRoles.Username.

Preferisco usare il nome non infetto, che in inglese sembra essere singolare.

L'inflessione del numero del nome della tabella causa problemi ortografici (come mostrano molte altre risposte), ma scegliere di farlo perché le tabelle di solito contengono più righe è anche semanticamente pieno di buchi. Questo è più ovvio se consideriamo un linguaggio che flette i nomi in base al caso (come la maggior parte fa):

Dato che di solito facciamo qualcosa con le righe, perché non inserire il nome nel caso accusativo? Se abbiamo una tabella a cui scriviamo più di quanto leggiamo, perché non mettere il nome in dativo? È una tabella di qualcosa, perché non usare il genitivo? Non lo faremmo, perché la tabella è definita come un contenitore astratto che esiste indipendentemente dal suo stato o utilizzo. Flettere il nome senza una ragione semantica precisa e assoluta è un borbottio.

L'uso del nome non infetto è semplice, logico, regolare e indipendente dalla lingua.

Quale convenzione richiede che le tabelle abbiano nomi singolari? Ho sempre pensato che fossero nomi plurali.

Un utente viene aggiunto alla tabella Users.

Questo sito è d'accordo:
http://vyaskn.tripod.com/object_naming.htm#Tables

Questo sito non è d'accordo (ma non sono d'accordo):
http://justinsomnia.org/writings/naming_conventions.html

Come altri hanno già detto: queste sono solo linee guida. Scegli una convenzione che funzioni per te e per la tua azienda / progetto e mantienila. Il passaggio tra parole singolari e plurali o talvolta abbreviate e talvolta no è molto più aggravante.

Che ne dici di questo come un semplice esempio:

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

vs.

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

L'SQL in quest'ultimo sembra più strano del primo.

Voto per singolare .

Sono fermamente convinto che in un diagramma di relazione tra entità, l'entità dovrebbe essere riflessa con un nome singolare, simile al nome di una classe che è singolare. Una volta istanziato, il nome riflette la sua istanza. Quindi, con i database, l'entità quando viene trasformata in una tabella (una raccolta di entità o record) è plurale. Entità, l'utente viene trasformato in utenti tabella. Concordo con gli altri che hanno suggerito che il nome Utente potrebbe essere migliorato come Dipendente o qualcosa di più applicabile al tuo scenario.

Questo ha quindi più senso in un'istruzione SQL perché stai selezionando da un gruppo di record e se il nome della tabella è singolare, non viene letto bene.

Mi attengo al singolare per i nomi delle tabelle e qualsiasi entità di programmazione.

La ragione? Il fatto che ci siano plurali irregolari in inglese come topo ⇒ topi e pecore ⇒ pecore . Quindi, se ho bisogno di una collezione , uso solo topi o pecore e vado avanti.

Aiuta davvero la spiccata pluralità e posso facilmente e programmaticamente determinare come sarebbe la raccolta di cose.

Quindi, la mia regola è: tutto è singolare, ogni raccolta di cose è singolare con una s aggiunta. Aiuta anche con ORM.

IMHO, i nomi delle tabelle dovrebbero essere plurali come i clienti .

I nomi delle classi devono essere singolari come quelli del Cliente se si associano a una riga nella tabella Clienti .

Singolare. Non compro nessun argomento che sia il più logico: ogni persona pensa che la propria preferenza sia il più logico. Non importa quello che fai è un casino, basta scegliere una convenzione e attenersi ad essa. Stiamo cercando di mappare una lingua con grammatica e semantica altamente irregolari (lingua parlata e scritta normale) su una grammatica altamente regolare (SQL) con semantica molto specifica.

Il mio argomento principale è che non penso alle tabelle come un insieme ma come relazioni.

Quindi, la AppUserrelazione dice quali entità sono AppUsers.

La AppUserGrouprelazione mi dice quali entità sonoAppUserGroups

La AppUser_AppUserGrouprelazione mi dice come l' AppUserse AppUserGroupssono legati.

La AppUserGroup_AppUserGrouprelazione mi dice come AppUserGroupse AppUserGroupssono correlati (cioè gruppi membri di gruppi).

In altre parole, quando penso alle entità e al modo in cui sono correlate, penso alle relazioni in modo singolare, ma ovviamente quando penso alle entità in raccolte o set, le raccolte o i set sono plurali.

Nel mio codice, quindi, e nello schema del database, uso singolare. Nelle descrizioni testuali, finisco per usare il plurale per una maggiore leggibilità, quindi uso i caratteri ecc. Per distinguere il nome della tabella / relazione dal plurale.

Mi piace pensarlo come disordinato, ma sistematico - e in questo modo c'è sempre un nome generato sistematicamente per la relazione che desidero esprimere, che per me è molto importante.

Vorrei anche andare con i plurali e con il suddetto dilemma degli utenti , adottiamo l'approccio del bracketing quadrato.

Facciamo questo per fornire l'uniformità tra l'architettura del database e l'architettura dell'applicazione, con la comprensione che la tabella Users è una raccolta di valori utente , così come una raccolta Users in un artefatto di codice è una raccolta di oggetti User .

Avere il nostro team di dati e i nostri sviluppatori che parlano lo stesso linguaggio concettuale (anche se non sempre gli stessi nomi di oggetti) rende più semplice trasmettere idee tra di loro.

Personalmente preferisco usare nomi plurali per rappresentare un insieme, semplicemente "suona" meglio alla mia mente relazionale.

In questo preciso momento sto usando nomi singolari per definire un modello di dati per la mia azienda, perché la maggior parte delle persone al lavoro si sente più a suo agio con esso. A volte devi solo rendere la vita più facile a tutti invece di imporre le tue preferenze personali. (è così che sono finito in questo thread, per ottenere una conferma su quella che dovrebbe essere la "best practice" per la denominazione delle tabelle)

Dopo aver letto tutte le discussioni in questa discussione, ho raggiunto una conclusione:

Mi piacciono le mie frittelle con miele, indipendentemente dal sapore preferito di tutti. Ma se sto cucinando per altre persone, cercherò di servire loro qualcosa che gli piace.

Singolare. Definirei un array contenente un gruppo di oggetti di rappresentazione delle righe utente "utenti", ma la tabella è "la tabella utente". Pensare alla tabella come nient'altro che l'insieme delle righe che contiene è sbagliato, IMO; la tabella è i metadati e l'insieme di righe è gerarchicamente collegato alla tabella, non è la tabella stessa.

Uso gli ORM per tutto il tempo, ovviamente, e aiuta il fatto che il codice ORM scritto con nomi di tabelle plurali sia stupido.

In realtà ho sempre pensato che fosse una convenzione popolare usare nomi di tabelle plurali. Fino a questo punto ho sempre usato il plurale.

Riesco a capire l'argomento per nomi di tabelle singolari, ma per me il plurale ha più senso. Un nome di tabella solitamente descrive cosa contiene la tabella. In un database normalizzato, ogni tabella contiene set specifici di dati. Ogni riga è un'entità e la tabella contiene molte entità. Quindi la forma plurale per il nome della tabella.

Un tavolo di macchine avrebbe il nome di macchine e ogni fila è una macchina. Devo ammettere che specificare la tabella insieme al campo in un table.fieldcerto modo è la migliore pratica e che avere nomi di tabella singolari è più leggibile. Tuttavia, nei seguenti due esempi, il primo ha più senso:

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

Onestamente, ripenserò la mia posizione sulla questione e farei affidamento sulle convenzioni effettivamente utilizzate dall'organizzazione per cui sto sviluppando. Tuttavia, penso che per le mie convenzioni personali, rimarrò con nomi di tabella plurale. Per me ha più senso.

Non mi piacciono i nomi di tabella plurale perché alcuni sostantivi in ​​inglese non sono numerabili (acqua, zuppa, denaro) o il significato cambia quando lo rendi numerabile (pollo vs pollo; carne vs uccello). Non mi piace anche usare le abbreviazioni per il nome della tabella o della colonna, perché in questo modo si aggiunge una pendenza extra alla curva di apprendimento già ripida.

Ironia della sorte, potrei fare Userun'eccezione e chiamarla a Userscausa di USER (Transac-SQL) , perché anche a me non piace usare le parentesi attorno alle tabelle se non devo.

Mi piace anche nominare tutte le colonne ID come Id, no ChickenIdo ChickensId(cosa fanno i plurali al riguardo?).

Tutto questo perché non ho il giusto rispetto per i sistemi di database, sto solo riapplicando la conoscenza di un pony da convenzioni di denominazione OO come Java per abitudine e pigrizia. Vorrei che ci fosse un miglior supporto IDE per SQL complicato.

Eseguiamo standard simili, quando gli script richiedono [] attorno ai nomi e laddove appropriato qualificatori di schemi - principalmente copre le tue scommesse contro future prese di nomi dalla sintassi SQL.

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

Ciò ha salvato le nostre anime in passato - alcuni dei nostri sistemi di database hanno funzionato per oltre 10 anni da SQL 6.0 a SQL 2005 - ben oltre la durata prevista.

Tabelle: plurale

Più utenti sono elencati nella tabella degli utenti.

Modelli: singolare

Un singolo utente può essere selezionato dalla tabella degli utenti.

Controller: plurale

http://myapp.com/users elencherebbe più utenti.

Questa è comunque la mia opinione.

Sono un fan dei nomi di tabelle singolari in quanto rendono più semplici da leggere i miei diagrammi ER utilizzando la sintassi CASE, ma leggendo queste risposte ho la sensazione che non abbia mai preso molto bene? Personalmente lo adoro. C'è una buona panoramica con esempi di quanto possano essere leggibili i tuoi modelli quando usi nomi di tabelle singolari, aggiungi verbi di azione alle tue relazioni e formi buone frasi per ogni relazione. È un po 'eccessivo per un database di 20 tabelle, ma se si dispone di un DB con centinaia di tabelle e un design complesso, come potranno mai capirlo gli sviluppatori senza un buon diagramma leggibile?

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

Per quanto riguarda il prefisso di tabelle e viste, odio assolutamente questa pratica. Non dare a nessuna persona alcuna informazione prima di dargli probabilmente cattive informazioni. Chiunque sfoglia un db alla ricerca di oggetti può facilmente distinguere una tabella da una vista, ma se ho una tabella denominata tblUsers che per qualche motivo decido di ristrutturare in futuro in due tabelle, con una vista unificante per evitare di rompere il vecchio codice Ora ho una vista chiamata tblUsers. A questo punto mi rimangono due opzioni poco interessanti, lascia una vista nominata con un prefisso tbl che può confondere alcuni sviluppatori, o forzare un altro livello, livello intermedio o applicazione da riscrivere per fare riferimento alla mia nuova struttura o agli utenti con nome. Ciò nega gran parte del valore delle visualizzazioni IMHO.

Il sistema tables/viewsdel server stesso ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, etc.) sono quasi sempre al plurale. Immagino che per coerenza seguirò il loro esempio.

Se guardiamo le MS SQL Server'stabelle di sistema, i loro nomi sono assegnati da Microsoft plural.

Le tabelle di sistema di Oracle sono nominate singular. Sebbene alcuni di essi siano plurali. Oracle consiglia il plurale per i nomi di tabella definiti dall'utente. Non ha molto senso che raccomandino una cosa e ne seguano un'altra. Che gli architetti di questi due giganti del software abbiano chiamato i loro tavoli usando convenzioni diverse, non ha molto senso neanche ... Dopotutto, cosa sono questi ragazzi ... dottorandi?

Ricordo che in ambito accademico la raccomandazione era singolare.

Ad esempio, quando diciamo:

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

forse b / c ognuno IDè selezionato da una particolare riga singola ...?

Questo potrebbe essere un po 'ridondante, ma suggerirei di essere cauto. Non è necessariamente una cosa negativa rinominare le tabelle, ma la standardizzazione è proprio questo; uno standard - questo database potrebbe già essere "standardizzato", per quanto malamente :) - Suggerirei che la coerenza sia un obiettivo migliore dato che questo database esiste già e presumibilmente è composto da più di 2 sole tabelle.

A meno che tu non possa standardizzare l'intero database, o almeno non stai pianificando di lavorare a tal fine, sospetto che i nomi delle tabelle siano solo la punta dell'iceberg e che si concentrino sul compito a portata di mano, sopportando il dolore di oggetti mal nominati, potrebbe essere in il tuo miglior interesse -

La coerenza pratica a volte è lo standard migliore ... :)

my2cents ---

Possibili alternative:

• Rinominare la tabella SystemUser
• Usa le parentesi
• Mantieni i nomi di tabella plurale.

L'utilizzo delle parentesi da parte dell'IMO è tecnicamente l'approccio più sicuro, sebbene sia un po 'complicato. L'IMO è il 6 dell'uno, mezza dozzina dell'altro e la tua soluzione si riduce davvero alle preferenze personali / del team.

La mia opinione è in semantica a seconda di come definisci il tuo contenitore. Ad esempio, un "sacchetto di mele" o semplicemente "mele" o un "sacchetto di mele" o "mela".

Esempio: una tabella "college" può contenere 0 o più college una tabella di "college" può contenere 0 o più college

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

La mia conclusione è che o va bene, ma devi definire come approverai te (o le persone che interagiscono con esso) quando ti riferisci alle tabelle; "ax table" o "table of xs"

Come altri hanno già detto qui, le convenzioni dovrebbero essere uno strumento da aggiungere alla facilità d'uso e alla leggibilità. Non come una catena o un club per torturare gli sviluppatori.

Detto questo, la mia preferenza personale è quella di usare nomi singolari sia per le tabelle che per le colonne. Questo probabilmente deriva dal mio background di programmazione. I nomi delle classi sono generalmente singolari a meno che non siano una sorta di raccolta. Nella mia mente sto memorizzando o leggendo singoli record nella tabella in questione, quindi singolare ha senso per me.

Questa pratica mi consente anche di riservare nomi di tabelle plurali a coloro che memorizzano relazioni molti-a-molti tra i miei oggetti.

Cerco anche di evitare parole riservate nei nomi delle mie tabelle e colonne. Nel caso in questione qui ha più senso andare in contrasto con la singolare convenzione per gli utenti per evitare la necessità di incapsulare una tabella che utilizza la parola riservata dell'utente.

Mi piace usare i prefissi in modo limitato (tbl per i nomi delle tabelle, sp_ per i nomi proc, ecc.), Anche se molti credono che questo aggiunga disordine. Preferisco anche i nomi CamelBack ai caratteri di sottolineatura perché finisco sempre per premere + invece di _ quando si digita il nome. Molti altri non sono d'accordo.

Ecco un altro buon link per le linee guida della convenzione di denominazione: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

Ricorda che il fattore più importante nella tua convenzione è che ha senso per le persone che interagiscono con il database in questione. Non esiste un "One Ring to Rule Them All" quando si tratta di convenzioni di denominazione.

Penso che usare il singolare sia ciò che ci è stato insegnato all'università. Ma allo stesso tempo si poteva sostenere che, diversamente dalla programmazione orientata agli oggetti, una tabella non è un'istanza dei suoi record.

Penso di essere a favore del singolare al momento a causa di irregolarità plurali in inglese. In tedesco è ancora peggio a causa della mancanza di forme plurali coerenti - a volte non si può dire se una parola è plurale o meno senza l'articolo che le specifica di fronte (der / die / das). E nelle lingue cinesi non ci sono comunque forme plurali.

Una volta ho usato "Amico" per la tabella Utente - stesso numero breve di caratteri, nessun conflitto con le parole chiave, ancora un riferimento a un essere umano generico. Se non fossi preoccupato per le teste chiuse che potrebbero vedere il codice, lo avrei mantenuto in quel modo.

Ho sempre usato il singolare semplicemente perché è quello che mi è stato insegnato. Tuttavia, durante la creazione di un nuovo schema di recente, per la prima volta dopo tanto tempo, ho deciso attivamente di mantenere questa convenzione semplicemente perché ... è più breve. Aggiungere una 's' alla fine di ogni nome di tabella mi sembra inutile come aggiungere 'tbl_' davanti a ognuno.

Ho sempre pensato che fosse una stupida convenzione. Uso nomi di tabelle plurali.

(Credo che la logica alla base di tale politica sia quella di rendere più semplice per i generatori di codice ORM la produzione di classi di oggetti e raccolte, poiché è più semplice produrre un nome plurale da un nome singolare piuttosto che viceversa)

Uso solo nomi per i nomi delle mie tabelle che sono scritti allo stesso modo, sia singolari che plurali:

pesce alce cervo aereo pantaloni pantaloncini occhiali forbici specie prole

Non l'ho visto chiaramente articolato in nessuna delle risposte precedenti. Molti programmatori non hanno in mente una definizione formale quando lavorano con le tabelle. Spesso comunichiamo in modo intuitivo in termini di "record" o "righe". Tuttavia, con alcune eccezioni per le relazioni denormalizzate, le tabelle sono generalmente progettate in modo tale che la relazione tra gli attributi non chiave e la chiave costituisca una funzione teorica definita.

Una funzione può essere definita come un sottoinsieme di un prodotto incrociato tra due insiemi, in cui ciascun elemento dell'insieme di chiavi si verifica al massimo una volta nella mappatura. Quindi la terminologia derivante da quella prospettiva tende ad essere singolare. Si vede la stessa convenzione singolare (o almeno non plurale) attraverso altre teorie matematiche e computazionali che coinvolgono funzioni (algebra e calcolo lambda per esempio).