Sto iniziando un nuovo progetto e vorrei ottenere i miei nomi di tabella e colonna fin dall'inizio. Ad esempio ho sempre usato il plurale nei nomi delle tabelle, ma recentemente ho imparato singolare è corretto.

Quindi, se ho una tabella "user" e poi ho prodotti che solo l'utente avrà, la tabella dovrebbe essere chiamata "user_product" o semplicemente "product"? Questa è una relazione uno a molti.

E più avanti, se avessi (per qualche motivo) diverse descrizioni dei prodotti per ciascun prodotto, sarebbe "user_product_description" o "product_description" o solo "description"? Naturalmente con le giuste chiavi esterne impostate ... Assegnare un nome solo alla descrizione sarebbe problematico poiché potrei avere anche la descrizione dell'utente o la descrizione dell'account o altro ...

E se volessi una tabella relazionale pura (da molte a molte) con solo due colonne, come sarebbe? "user_stuff" o forse qualcosa come "rel_user_stuff"? E se il primo, cosa lo distinguerebbe, ad esempio "user_product"?

Qualsiasi aiuto è molto apprezzato e se c'è una sorta di convenzione sulla denominazione là fuori che voi ragazzi raccomandate, sentitevi liberi di collegarvi.

Grazie

Tabella • Nome

il singolare appreso di recente è corretto

Sì. Attenzione ai pagani. Plurale nei nomi delle tabelle è un segno sicuro di qualcuno che non ha letto nessuno dei materiali standard e non ha conoscenza della teoria dei database.

Alcune delle cose meravigliose sugli standard sono:

• sono tutti integrati l'uno con l'altro
• lavorano insieme
• sono stati scritti da menti più grandi delle nostre, quindi non dobbiamo discuterle.

Il nome della tabella standard si riferisce a ciascuna riga della tabella, che viene utilizzata in tutte le parole, non al contenuto totale della tabella (sappiamo che la Customertabella contiene tutti i clienti).

Relazione, frase del verbo

In autentici database relazionali che sono stati modellati (al contrario dei sistemi di archiviazione dei record precedenti agli anni '70 [caratterizzati dai Record IDsquali sono implementati in un contenitore di database SQL per comodità):

• le tabelle sono i soggetti del database, quindi sono sostantivi , ancora una volta singolari
• le relazioni tra le tabelle sono le Azioni che si svolgono tra i sostantivi, quindi sono verbi (cioè non sono arbitrariamente numerati o denominati)
• quello è il Predicato
• tutto ciò che può essere letto direttamente dal modello di dati (consultare i miei esempi alla fine)
• (il predicato per una tabella indipendente (il genitore più in alto in una gerarchia) è che è indipendente)
• quindi la frase del verbo viene scelta con cura, in modo che sia la più significativa, e si evitano i termini generici (questo diventa più facile con l'esperienza). La frase del verbo è importante durante la modellazione perché aiuta a risolvere il modello, ad es. chiarire le relazioni, identificare gli errori e correggere i nomi delle tabelle.

Diagram_A

Naturalmente, la relazione è implementata in SQL come CONSTRAINT FOREIGN KEYnella tabella figlio (più avanti). Ecco la frase verbale (nel modello), il predicato che rappresenta (da leggere dal modello) e il nome del vincolo FK :

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

Tabella • Lingua

Tuttavia, quando si descrive la tabella, in particolare in un linguaggio tecnico come i Predicati o altra documentazione, utilizzare singolari e plurali come naturalmente nella lingua inglese. Tenendo presente che la tabella è denominata per la singola riga (relazione) e la lingua si riferisce a ciascuna riga derivata (relazione derivata):

    Each Customer initiates zero-to-many SalesOrders

non

    Customers have zero-to-many SalesOrders 

Quindi, se ho una tabella "user" e poi ho prodotti che solo l'utente avrà, la tabella dovrebbe essere chiamata "user-product" o semplicemente "product"? Questa è una relazione uno a molti.

(Questa non è una domanda sulla convenzione di denominazione; questa è una domanda di progettazione di db.) Non importa se user::productè 1 :: n. Ciò che conta è se si producttratta di un'entità separata e se si tratta di una tabella indipendente , vale a dire. può esistere da solo. Pertanto productno user_product.

E se productesiste solo nel contesto di un user, cioè. è una tabella dipendente , quindi user_product.

Diagram_B

E più avanti, se avessi (per qualche motivo) diverse descrizioni dei prodotti per ciascun prodotto, sarebbe "descrizione-prodotto-utente" o "descrizione-prodotto" o solo "descrizione"? Naturalmente con le giuste chiavi esterne impostate .. Assegnare un nome solo alla descrizione sarebbe problematico poiché potrei avere anche la descrizione dell'utente o la descrizione dell'account o altro.

Giusto. O user_product_descriptionxor product_descriptionsarà corretto, in base a quanto sopra. Non è per differenziarlo dagli altri xxxx_descriptions, ma è per dare al nome un senso di dove appartiene, il prefisso è la tabella padre.

E se volessi una tabella relazionale pura (da molte a molte) con solo due colonne, come sarebbe? "user-stuff" o forse qualcosa come "rel-user-stuff"? E se il primo, cosa lo distinguerebbe, ad esempio "user-product"?

1. Si spera che tutte le tabelle nel database relazionale siano pure tabelle relazionali e normalizzate. Non è necessario identificarlo nel nome (altrimenti saranno presenti tutte le tabelle rel_something).

2. Se contiene solo i PK dei due genitori (che risolve la relazione logica n :: n che non esiste come entità a livello logico, in una tabella fisica ), quella è una tabella associativa . Sì, in genere il nome è una combinazione dei due nomi di tabella padre.

   • Nota che in questi casi la frase del verbo si applica e viene letta da genitore a genitore, ignorando la tabella figlio, poiché il suo unico scopo nella vita è mettere in relazione i due genitori.

     Diagram_C

   • Se è non una tabella associativa (es. In aggiunta ai due PK, contiene dati), quindi un nome appropriato, e le frasi verbali applicano ad esso, non il genitore alla fine del rapporto.

     Diagram_D

3. Se finisci con due user_producttabelle, allora è un segnale molto forte che non hai normalizzato i dati. Quindi torna indietro di alcuni passaggi e fallo, e dai un nome alle tabelle in modo accurato e coerente. I nomi si risolveranno da soli.

Convenzione di denominazione

Qualsiasi aiuto è molto apprezzato e se c'è una sorta di convenzione sulla denominazione là fuori che voi ragazzi raccomandate, sentitevi liberi di collegarvi.

Quello che stai facendo è molto importante e influenzerà la facilità d'uso e la comprensione a tutti i livelli. Quindi è bene avere più comprensione possibile all'inizio. La pertinenza della maggior parte di questo non sarà chiara fino a quando non inizierai a scrivere codice in SQL.

1. Il caso è il primo oggetto da affrontare. Tutte le protezioni sono inaccettabili. Il caso misto è normale, soprattutto se le tabelle sono direttamente accessibili dagli utenti. Consultare i miei modelli di dati. Si noti che quando il ricercatore sta usando un NonSQL demente, che ha solo lettere minuscole, lo dico, nel qual caso includo caratteri di sottolineatura (come nei tuoi esempi).

2. Mantenere un focus sui dati , non un'applicazione o un focus sull'utilizzo. Dopo tutto il 2011, abbiamo avuto Open Architecture dal 1984 e i database dovrebbero essere indipendenti dalle app che li utilizzano.

   In questo modo, man mano che crescono e più di quanto l'app li usi, i nomi rimarranno significativi e non necessitano di correzioni. (I database che sono completamente integrati in una singola app non sono database.) Denominare gli elementi di dati solo come dati.

3. Sii molto premuroso e assegna un nome alle tabelle e alle colonne in modo molto preciso . Non utilizzare UpdatedDatese si tratta di un DATETIMEtipo di dati, utilizzare UpdatedDtm. Non usare _descriptionse contiene un dosaggio.

4. È importante essere coerenti in tutto il database. Non utilizzare NumProductin un posto per indicare il numero di prodotti e ItemNoo ItemNumin un altro posto per indicare il numero di articoli. Utilizzare NumSomethingper numero di, e SomethingNoo SomethingIdper identificatori, in modo coerente.

5. Non aggiungere il prefisso al nome della colonna con un nome di tabella o un codice funzione, ad esempio user_first_name. SQL fornisce già il nome tabl come qualificatore:

       table_name.column_name  -- notice the dot
   

6. eccezioni:

   • La prima eccezione è per i PK, hanno bisogno di una gestione speciale perché li codifichi sempre nei join e vuoi che le chiavi si distinguano dalle colonne di dati. Usa sempre user_id, mai id.

     • Si noti che questo non è un nome di tabella usato come prefisso, ma un nome descrittivo appropriato per il componente della chiave: user_idè la colonna che identifica un utente, non quella iddella usertabella.
       • (Tranne ovviamente nei sistemi di archiviazione dei record, in cui i surrogati accedono ai file e non ci sono chiavi relazionali, ci sono la stessa cosa).
     • Utilizzare sempre lo stesso nome esatto per la colonna chiave ovunque il PK sia trasportato (migrato) come FK.
     • Pertanto la user_producttabella avrà user_idun componente come suo PK (user_id, product_no).
     • la rilevanza di questo diventerà chiara quando inizi a scrivere codice. Innanzitutto, con idmolte tabelle, è facile confondersi con la codifica SQL. In secondo luogo, chiunque altro che il programmatore iniziale non avesse idea di cosa stesse cercando di fare. Entrambi sono facili da prevenire, se le colonne chiave sono trattate come sopra.

   • La seconda eccezione è quella in cui vi è più di un FK che fa riferimento alla stessa tabella della tabella padre, presente nel figlio. Secondo il modello relazionale , utilizzare i nomi dei ruoli per differenziare il significato o l'utilizzo, ad es. AssemblyCodee ComponentCodeper due PartCodes. E in quel caso, non usare l'indifferenziato PartCodeper uno di loro. Sii preciso.

     Diagram_E

7. Prefisso
   Se hai più di 100 tabelle, aggiungi i nomi delle tabelle con un'area tematica:

   REF_per le tabelle di riferimento
   OE_per il cluster di inserimento ordini, ecc.

   Solo a livello fisico, non logico (ingombra il modello).

8. Suffisso
   Non usare mai suffissi sulle tabelle e usare sempre suffissi su tutto il resto. Ciò significa che nell'uso logico e normale del database, non ci sono caratteri di sottolineatura; ma dal lato amministrativo, i trattini bassi sono usati come separatore:

   _VVisualizza (con il principale TableNamedavanti, ovviamente)
   _fkChiave esterna (il nome del vincolo, non il nome della colonna ) Funzione di transazione del segmento di
   _caccache (proc memorizzata o funzione) Funzione (non transazionale), ecc.
   _seg
_tr
_fn

   Il formato è il nome della tabella o FK, un carattere di sottolineatura e il nome dell'azione, un carattere di sottolineatura e infine il suffisso.

   Questo è davvero importante perché quando il server ti dà un messaggio di errore:

   ____blah blah blah error on object_name

   sai esattamente quale oggetto è stato violato e cosa stava cercando di fare:

   ____blah blah blah error on Customer_Add_tr

9. Chiavi esterne (il vincolo, non la colonna). La migliore denominazione per un FK è usare la frase del verbo (meno "ciascuno" e la cardinalità).

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

   Usa la Parent_Child_fksequenza, non Child_Parent_fkperché (a) si presenta nell'ordinamento corretto quando li cerchi e (b) conosciamo sempre il bambino coinvolto, quello che stiamo indovinando è, quale genitore. Il messaggio di errore è quindi delizioso:

   ____ Foreign key violation on Vendor_Offers_PartVendor_fk.

   Funziona bene per le persone che si preoccupano di modellare i loro dati, in cui sono state identificate le frasi di verbo. Per il resto, usano i sistemi di archiviazione dei record, ecc Parent_Child_fk.

10. Gli indici sono speciali, quindi hanno una propria convenzione di denominazione, composta da, in ordine , ogni posizione del personaggio da 1 a 3:

    UUnico o _per un
    Ccluster non univoco o _per un
    _separatore non cluster

    Per il resto:

    • Se la chiave è una colonna o poche colonne:
      ____ColumnNames

    • Se la chiave è più di alcune colonne:
      ____ PKChiave primaria (come da modello)
      ____ AK[*n*]Chiave alternativa (termine IDEF1X)

    Si noti che il nome della tabella non è richiesto nel nome dell'indice, poiché viene sempre visualizzato cometable_name.index_name.

    Quindi quando Customer.UC_CustomerIdo Product.U__AKappare in un messaggio di errore, ti dice qualcosa di significativo. Quando guardi gli indici su una tabella, puoi differenziarli facilmente.

11. Trova qualcuno qualificato e professionale e seguilo. Guarda i loro progetti e studia attentamente le convenzioni di denominazione che usano. Poni loro domande specifiche su tutto ciò che non capisci. Al contrario, corri come l'inferno da chiunque mostri poco rispetto per le convenzioni o gli standard sui nomi. Eccone alcuni per iniziare:

    • Contengono esempi reali di tutto quanto sopra. Poni domande in merito alla denominazione delle domande in questo thread.
    • Naturalmente, i modelli implementano molti altri standard, oltre alle convenzioni di denominazione; puoi ignorarli per ora o sentirti libero di porre nuove domande specifiche .
    • Sono diverse pagine ciascuna, il supporto di immagini in linea su Stack Overflow è per gli uccelli e non si caricano in modo coerente su browser diversi; quindi dovrai fare clic sui collegamenti.
    • Nota che i file PDF hanno una navigazione completa, quindi fai clic sui pulsanti di vetro blu o sugli oggetti in cui viene identificata l'espansione:
    • I lettori che non hanno familiarità con lo standard di modellazione relazionale possono trovare utile la notazione IDEF1X .

Immissione ordini e inventario con indirizzi conformi agli standard

Semplice sistema di bollettini inter-ufficio per PHP / MyNonSQL

Monitoraggio del sensore con piena capacità temporale

Risposte alle domande

^{Non è possibile rispondere ragionevolmente nello spazio dei commenti.}

Larry Lustig:
... anche l'esempio più banale mostra ...
Se un cliente ha zero-a-molti prodotti e un prodotto ha uno-a-molti componenti e un componente ha uno-a-molti fornitori e un fornitore vende zero -to-molti componenti e un SalesRep ha uno-a molti clienti quali sono i nomi "naturali" delle tabelle che contengono clienti, prodotti, componenti e fornitori?

Ci sono due problemi principali nel tuo commento:

1. Dichiara il tuo esempio come "il più banale", tuttavia è tutt'altro. Con quel tipo di contraddizione, non sono sicuro che tu sia serio, se tecnicamente capace.

2. Quella speculazione "banale" ha diversi errori di normalizzazione (DB Design) grossolani.

   • Fino a quando non li correggi, sono innaturali e anormali e non hanno alcun senso. Potresti anche chiamarli anomal_1, abnormal_2, ecc.

   • Hai "fornitori" che non forniscono nulla; riferimenti circolari (illegali e non necessari); i clienti che acquistano prodotti senza strumenti commerciali (come Fattura o SalesOrder) come base per l'acquisto (o i clienti "possiedono" prodotti?); relazioni molti-a-irrisolte; eccetera.

   • Una volta che è stato normalizzato e le tabelle richieste sono state identificate, i loro nomi diventeranno ovvi. Naturalmente.

In ogni caso, proverò a soddisfare la tua richiesta. Ciò significa che dovrò aggiungere un po 'di senso ad esso, non sapendo cosa volevi dire, quindi per favore abbi pazienza. Gli errori grossolani sono troppi da elencare e, date le specifiche di riserva, non sono sicuro di averli corretti tutti.

• Presumo che se il prodotto è costituito da componenti, il prodotto è un assieme e i componenti vengono utilizzati in più di un assieme.

• Inoltre, poiché "Il fornitore vende zero-a-molti componenti", che non vendono prodotti o assiemi, vendono solo componenti.

Speculazione vs modello normalizzato

Se non si è consapevoli, la differenza tra gli angoli quadrati (Indipendente) e gli angoli arrotondati (Dipendente) è significativa, fare riferimento al collegamento Notazione IDEF1X. Allo stesso modo le linee continue (identificativo) vs le linee tratteggiate (non identificativo).

... quali sono i nomi "naturali" che contengono tabelle, clienti, prodotti, componenti e fornitori?

• Cliente
• Prodotto
• Componente (O, AssemblyComponent, per coloro che si rendono conto che un fatto identifica l'altro)
• Fornitore

Ora che ho risolto le tabelle, non capisco il tuo problema. Forse puoi pubblicare una domanda specifica .

VoteCoffee:
come stai gestendo lo scenario pubblicato da Ronnis nel suo esempio in cui esistono più relazioni tra 2 tabelle (user_likes_product, user_bought_product)? Potrei fraintendere, ma questo sembra tradursi in nomi di tabella duplicati usando la convenzione da te dettagliata.

Supponendo che non vi siano errori di normalizzazione, User likes Productè un predicato, non una tabella. Non confonderli. Fare riferimento alla mia risposta, in cui si riferisce a soggetti, verbi e predicati e la mia risposta a Larry immediatamente sopra.

• Ogni tabella contiene un insieme di fatti (ogni riga è un fatto). I predicati (o le proposizioni) non sono fatti, possono o meno essere veri.

  • Il modello relazionale si basa sul calcolo del predicato del primo ordine (più comunemente noto come logica del primo ordine). Un predicato è una frase a frase singola in inglese semplice e preciso, che valuta vero o falso.

  • Inoltre, ogni tabella rappresenta, o è l'implementazione di molti Predicati, non uno.

• Una query è un test di un Predicato (o un numero di Predicati, concatenati insieme) che risulta vero (il Fatto esiste) o falso (il Fatto non esiste).

• Quindi le tabelle dovrebbero essere nominate, come dettagliato nella mia risposta (convenzioni di denominazione), per la riga, il Fatto e i Predicati dovrebbero essere documentati (in ogni caso, fa parte della documentazione del database), ma come un elenco separato di Predicati .

• Questo non è un suggerimento che non sono importanti. Sono molto importanti, ma non lo scriverò qui.

• Quindi rapidamente. Poiché il Modello relazionale è basato su FOPC, si può dire che l'intero database è un insieme di dichiarazioni FOPC, un insieme di Predicati. Ma (a) ci sono molti tipi di Predicati e (b) una tabella non rappresenta un Predicato (è l'implementazione fisica di molti Predicati e di diversi tipi di Predicati).

• Pertanto nominare la tabella per "il" Predicato che "rappresenta" è un concetto assurdo.

• I "teorici" sono a conoscenza di pochi Predicati, non comprendono che da quando il RM è stato fondato sul FOL, l'intero database è un insieme di Predicati e di diversi tipi.

  • E, naturalmente, scelgono quelli assurdi tra i pochi che conoscono EXISTING_PERSON:; PERSON_IS_CALLED. Se non fosse così triste, sarebbe divertente.

  • Si noti inoltre che il nome di tabella atomica o standard (denominazione della riga) funziona in modo eccellente per tutte le verbosità (inclusi tutti i predicati allegati alla tabella). Al contrario, il nome "tabella rappresenta predicato" idiota non può. Il che va bene per i "teorici", che capiscono molto poco sui Predicati, ma ritardano diversamente.

• I predicati che sono rilevanti per il modello di dati, sono espressi nel modello, sono di due ordini.

  1. Predicato unario
     Il primo set è schematico , non testuale: la notazione stessa . Questi includono vari esistenziali; Vincolo orientato; e descrittori (attributi) Predicati.

     • Ovviamente, ciò significa che solo coloro che possono "leggere" un modello di dati standard possono leggere quei Predicati. Questo è il motivo per cui i "teorici", che sono gravemente paralizzati dalla loro mentalità di solo testo, non possono leggere modelli di dati, perché si attaccano alla loro mentalità di solo testo pre-1984.

  2. Predicato binario
     Il secondo set è quello che forma relazioni tra Fatti. Questa è la linea di relazione. La frase del verbo (dettagliata sopra) identifica il Predicato, la proposizione , che è stata implementata (che può essere testata tramite query). Non si può essere più espliciti di così.

     • Pertanto, per chi è fluente nei modelli di dati standard, tutti i Predicati rilevanti sono documentati nel modello. Non hanno bisogno di un elenco separato di predicati (ma gli utenti, che non possono "leggere" tutto dal modello di dati, lo fanno!).

• Ecco un modello di dati , in cui ho elencato i predicati. Ho scelto quell'esempio perché mostra i Predicati esistenziali, ecc., Così come quelli della relazione, gli unici Predicati non elencati sono i descrittori. Qui, a causa del livello di apprendimento del ricercatore, lo sto trattando come un utente.

Pertanto, l'evento di più di una tabella figlio tra due tabelle principali non è un problema, basta denominarli come Fatto esistenziale in relazione al loro contenuto e normalizzare i nomi.

Le regole che ho dato per le frasi dei verbi per i nomi delle relazioni per le tabelle associative entrano in gioco qui. Ecco una discussione Predicato vs Tavolo , che copre tutti i punti menzionati, in sintesi.

Per una breve descrizione dell'uso corretto dei Predicati e di come usarli (che è un contesto abbastanza diverso da quello di rispondere ai commenti qui), visitare questa risposta e scorrere fino alla sezione Predicato .

Charles Burns:
Per sequenza intendevo l'oggetto in stile Oracle usato esclusivamente per memorizzare un numero e il suo successivo secondo una regola (ad esempio "aggiungi 1"). Poiché Oracle non dispone di tabelle con ID automatico, il mio uso tipico è generare ID univoci per le tabelle PK. INSERISCI IN foo (id, somedata) VALUES (foo_s.nextval, "data" ...)

Ok, questo è ciò che chiamiamo tabella Key o NextKey. Nomina come tale. Se si dispone di SubjectAreas, utilizzare COM_NextKey per indicare che è comune nel database.

A proposito, questo è un metodo molto scarso per generare chiavi. Non è affatto scalabile, ma quindi con le prestazioni di Oracle, probabilmente va "bene". Inoltre, indica che il database è pieno di surrogati, non relazionali in quelle aree. Ciò significa prestazioni estremamente scarse e mancanza di integrità.

Singolare vs. plurale: scegline uno e mantienilo.

Le colonne non dovrebbero essere prefissate / suffissate / infisse o comunque riparate con riferimenti al fatto che si tratta di una colonna. Lo stesso vale per i tavoli. Non nominare le tabelle EMPLOYEE_T o TBL_EMPLOYEES perché il secondo viene sostituito con una vista, le cose diventano davvero confuse.

Non incorporare informazioni sul tipo nei nomi, come "vc_firstname" per varchar o "flavour_enum". Inoltre, non incorporare vincoli nei nomi delle colonne, come "department_fk" o "employee_pk".

In realtà, l'unica cosa buona di correzioni * mi viene in mente, è che è possibile utilizzare parole riservate come where_t, tbl_order, user_vw. Ovviamente, in quegli esempi, l'uso del plurale avrebbe risolto il problema :)

Non nominare tutte le chiavi "ID". Le chiavi che si riferiscono alla stessa cosa, dovrebbero avere lo stesso nome in tutte le tabelle. La colonna ID utente potrebbe essere chiamata USER_ID nella tabella utente e tutte le tabelle che fanno riferimento all'utente. L'unica volta che viene rinominato è quando utenti diversi svolgono ruoli diversi, come ad esempio Messaggio (sender_user_id, receiver_user_id). Questo aiuta davvero quando si gestiscono query più grandi.

Per quanto riguarda CaSe:

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

In generale, è meglio denominare "tabelle di mapping" in modo che corrispondano alla relazione che descrive piuttosto che ai nomi delle tabelle di riferimento. Un utente può avere qualsiasi numero di rapporti con i prodotti: user_likes_product, user_bought_product, user_wants_to_buy_product.

Non esiste un "corretto" tra singolare e plurale - è principalmente una questione di gusti.

Dipende in parte dalla tua concentrazione. Se pensi alla tabella come a un'unità, contiene "plurali" (perché contiene molte righe, quindi un nome plurale è appropriato). Se pensi al nome della tabella come identificando una riga in una tabella, preferirai "singolare". Ciò significa che il tuo SQL verrà considerato come funzionante su una riga dalla tabella. Va bene, anche se di solito è una semplificazione eccessiva; SQL funziona su set (più o meno). Tuttavia, possiamo andare con singolare per le risposte a questa domanda.

1. Poiché probabilmente avrai bisogno di una tabella "user", di un altro "prodotto" e del terzo per connettere gli utenti ai prodotti, allora avrai bisogno di una tabella "user_product".

2. Poiché la descrizione si applica a un prodotto, utilizzare "descrizione_prodotto". A meno che ogni utente non denomini ogni prodotto per se stesso ...

3. La tabella 'user_product' è (o potrebbe essere) un esempio di una tabella con un ID prodotto e un ID utente e non molto altro. Le tabelle con due attributi vengono denominate nello stesso modo generale: "user_stuff". I prefissi decorativi come 'rel_' non aiutano davvero. Vedrai alcune persone che usano 't_' davanti al nome di ogni tabella, per esempio. Questo non è di grande aiuto.

I plurali non sono male finché sono usati in modo coerente - ma la mia preferenza è singolare.

Vorrei rinunciare ai caratteri di sottolineatura a meno che tu non voglia delineare una relazione molti-a-molti; e usa un capitale iniziale perché aiuta a distinguere le cose negli ORM.

Ma ci sono molte convenzioni di denominazione, quindi se vuoi usare i trattini bassi va bene fintanto che è fatto in modo coerente.

Così:

User

UserProduct (it is a users products after all)

Se solo un utente può avere qualsiasi prodotto, allora

UserProductDescription

Ma se il prodotto è condiviso dagli utenti:

ProductDescription

Se salvi i caratteri di sottolineatura per relazioni molti-a-molti, puoi fare qualcosa del tipo:

UserProduct_Stuff

per formare un M-to-M tra UserProduct e Stuff - non sono sicuro dalla domanda l'esatta natura del molti-a-molti richiesto.

Non è più corretto usare una forma singolare che plurale, dove l'hai sentito? Preferirei dire che la forma plurale è più comune per la denominazione delle tabelle del database ... e secondo me anche più logica. La tabella contiene spesso più di una riga;) In un modello concettuale sebbene i nomi delle entità siano spesso in singolare.

Per quanto riguarda la tua domanda, se "Product" e "ProductDescription" sono concetti con un'identità (es. Entità) nel tuo modello, chiamerei semplicemente le tabelle "Products" e "ProductDescription". Per le tabelle utilizzate al fine di implementare una relazione molti-a-molti, spesso utilizzo la convenzione di denominazione "SideA2SideB", ad esempio "Student2Course".