Convenzioni di denominazione di database, tabelle e colonne? [chiuso]

Ogni volta che progetto un database, mi chiedo sempre se esiste un modo migliore di nominare un elemento nel mio database. Molto spesso mi pongo le seguenti domande:

1. I nomi delle tabelle dovrebbero essere plurali?
2. I nomi delle colonne dovrebbero essere singolari?
3. Devo anteporre tabelle o colonne?
4. Dovrei usare un caso per nominare gli articoli?

Esistono linee guida consigliate per la denominazione degli elementi in un database?

Consiglio di consultare i database di esempio di SQL Server di Microsoft: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

L'esempio AdventureWorks utilizza una convenzione di denominazione molto chiara e coerente che utilizza nomi di schema per l'organizzazione di oggetti di database.

1. Nomi singolari per le tabelle
2. Nomi singolari per colonne
3. Nome schema per prefisso tabelle (ad es. SchemeName.TableName)
4. Involucro Pascal (aka custodia in cammello superiore)

Risposta in ritardo qui, ma in breve:

1. La mia preferenza è al plurale
2. sì
3. Tabelle : * Di solito * nessun prefisso è il migliore. Colonne : No.
4. Sia tabelle che colonne: PascalCase.

Elaborazione:

(1) Cosa devi fare. Ci sono pochissime cose che devi fare in un certo modo, ogni volta, ma ce ne sono alcune.

• Assegna un nome alle chiavi primarie utilizzando il formato "ID [singularOfTableName]". Ovvero, sia che il nome della tabella sia Cliente o Clienti , la chiave primaria dovrebbe essere CustomerID .
• Inoltre, le chiavi esterne devono essere denominate in modo coerente in tabelle diverse. Dovrebbe essere legale picchiare qualcuno che non lo fa. Sottolineerei che mentre i vincoli di chiave esterna definiti sono spesso importanti, la denominazione coerente delle chiavi esterne è sempre importante
• Il database deve avere convenzioni interne . Anche se nelle sezioni successive mi vedrai molto flessibile, all'interno di un database la denominazione deve essere molto coerente. Indipendentemente dal fatto che la tabella per i clienti sia denominata Clienti o Cliente, è meno importante che lo si faccia nello stesso database. E puoi lanciare una moneta per determinare come usare i trattini bassi, ma poi devi continuare a usarli allo stesso modo . Se non lo fai, sei una persona cattiva che dovrebbe avere una bassa autostima.

(2) Cosa dovresti probabilmente fare.

• I campi che rappresentano lo stesso tipo di dati su tabelle diverse devono essere denominati uguali. Non avere Zip su un tavolo e ZipCode su un altro.
• Per separare le parole nei nomi delle tabelle o delle colonne, usa PascalCasing. L'uso di CamelCasing non sarebbe intrinsecamente problematico, ma questa non è la convenzione e sembrerebbe divertente. Tratterò i trattini bassi tra un momento. (Non puoi usare ALLCAPS come ai vecchi tempi. OBNOXIOUSTABLE.ANNOYING_COLUMN andava bene in DB2 20 anni fa, ma non ora.)
• Non abbreviare o abbreviare artificialmente le parole. È meglio che un nome sia lungo e chiaro che breve e confuso. I nomi ultra-corti rappresentano un passaggio dai tempi più scuri e più selvaggi. Cus_AddRef. Cosa diavolo è quello? Riferimento del destinatario custodiale? Rimborso aggiuntivo del cliente? Referral indirizzo personalizzato?

(3) Cosa dovresti considerare.

• Penso davvero che dovresti avere nomi plurali per le tabelle; alcuni pensano singolare. Leggi gli argomenti altrove. I nomi delle colonne dovrebbero essere singolari comunque. Anche se usi nomi di tabelle plurali, le tabelle che rappresentano combinazioni di altre tabelle potrebbero essere al singolare. Ad esempio, se si dispone di una tabella Promozioni e Articoli , una tabella che rappresenta un articolo che fa parte di una promozione potrebbe essere Promozioni_Articoli, ma potrebbe anche legittimamente essere Promozione_Articoli penso (che riflette la relazione uno-a-molti).
• Usa i trattini bassi in modo coerente e per uno scopo particolare. Solo i nomi delle tabelle generali dovrebbero essere abbastanza chiari con PascalCasing; non hai bisogno di trattini bassi per separare le parole. Salva i caratteri di sottolineatura (a) per indicare una tabella associativa o (b) per il prefisso, che affronterò nel prossimo punto.
• Il prefisso non è né buono né cattivo. Di solito non è il massimo. Nel tuo primo o secondo db, non suggerirei di utilizzare i prefissi per il raggruppamento tematico generale di tabelle. Le tabelle finiscono per non adattarsi facilmente alle tue categorie e può effettivamente rendere più difficile trovare le tabelle. Con l'esperienza, puoi pianificare e applicare uno schema di prefisso che fa più bene che male. Una volta ho lavorato in un db dove le tabelle di dati sono iniziate con tbl , le tabelle di configurazione con ctbl , le visualizzazioni con vew , proc's sp e udf's fne pochi altri; è stato meticolosamente, applicato in modo coerente, quindi ha funzionato bene. L'unica volta in cui hai BISOGNO dei prefissi è quando hai soluzioni veramente separate che per qualche ragione risiedono nello stesso db; il prefisso può essere molto utile nel raggruppare le tabelle. Il prefisso va bene anche per situazioni speciali, come per le tabelle temporanee che si desidera distinguere.
• Molto raramente (se mai) vorresti aggiungere un prefisso alle colonne.

Ok, dato che valutiamo l'opinione:

Credo che i nomi delle tabelle dovrebbero essere al plurale. Le tabelle sono una raccolta (una tabella) di entità. Ogni riga rappresenta una singola entità e la tabella rappresenta la raccolta. Quindi chiamerei una tabella di entità Person Persone (o Persone, qualunque cosa tu voglia).

Per coloro a cui piace visualizzare singolari "nomi di entità" nelle query, è quello che utilizzerei gli alias di tabella per:

SELECT person.Name
FROM People person

Un po 'come LINQ "from person in people select person.Name".

Per quanto riguarda 2, 3 e 4, sono d'accordo con @Lars.

Lavoro in un team di supporto per database con tre DBA e le nostre opzioni considerate sono:

1. Qualsiasi standard di denominazione è migliore di nessuno standard.
2. Non esiste un "unico vero" standard, tutti abbiamo le nostre preferenze
3. Se è già presente uno standard, utilizzalo. Non creare un altro standard o confondere gli standard esistenti.

Usiamo nomi singolari per le tabelle. Le tabelle tendono ad avere il prefisso con il nome del sistema (o il suo acronimo). Ciò è utile se il sistema è complesso in quanto è possibile modificare il prefisso per raggruppare le tabelle in modo logico (ad es. Reg_customer, reg_booking e regadmin_limits).

Per i campi prevediamo che i nomi dei campi includano il prefisso / acryonm della tabella (es. Indirizzo_cust1) e preferiamo anche l'uso di un set standard di suffissi (_id per il PK, _cd per "code", _nm per "name" ", _nb per" numero ", _dt per" Data ").

Il nome del campo Chiave Foriegn deve essere uguale al campo Chiave primaria.

vale a dire

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

Durante lo sviluppo di un nuovo progetto, ti consiglio di scrivere tutti i nomi di entità, prefissi e acronimi preferiti e di consegnare questo documento ai tuoi sviluppatori. Quindi, quando decidono di creare una nuova tabella, possono fare riferimento al documento anziché "indovinare" come dovrebbero essere chiamati la tabella e i campi.

1. No. Una tabella dovrebbe essere chiamata come l'entità che rappresenta. Persona, non persone è come faresti riferimento a chiunque rappresenti uno dei registri.
2. Ancora una volta, stessa cosa. La colonna FirstName in realtà non dovrebbe essere chiamata FirstNames. Tutto dipende da cosa vuoi rappresentare con la colonna.
3. NO.
4. Sì. Caso per chiarezza. Se devi avere colonne come "FirstName", il case renderà più facile la lettura.

Ok. Questo è il mio $ 0,02

Sono anche a favore di una convenzione di denominazione in stile ISO / IEC 11179, osservando che sono linee guida piuttosto che prescrittive.

Vedi Nome dell'elemento dati su Wikipedia :

"Le tabelle sono raccolte di entità e seguono le linee guida per la denominazione delle raccolte. Idealmente, viene utilizzato un nome collettivo: ad es., Personale. Plurale è anche corretto: Impiegati. I nomi errati includono: Impiegato, tblEmployee e EmployeeTable."

Come sempre, ci sono eccezioni alle regole, ad esempio una tabella che ha sempre esattamente una riga può essere migliore con un nome singolare, ad esempio una tabella di configurazione. E la coerenza è della massima importanza: controlla se il tuo negozio ha una convenzione e, in tal caso, seguila; se non ti piace, fai un caso aziendale per cambiarlo piuttosto che essere il ranger solitario.

Sento sempre l'argomentazione secondo cui se un tavolo è o meno pluralizzato è tutta una questione di gusti personali e non esiste una buona pratica. Non credo sia vero, soprattutto come programmatore rispetto a un DBA. Per quanto ne so, non ci sono ragioni legittime per pluralizzare un nome di tabella diverso da "Ha senso solo perché è una raccolta di oggetti", mentre ci sono guadagni legittimi nel codice con nomi di tabella singolari. Per esempio:

1. Evita bug ed errori causati da ambiguità plurali. I programmatori non sono esattamente conosciuti per la loro competenza ortografica e il pluralismo di alcune parole è confuso. Ad esempio, la parola plurale termina con 'es' o semplicemente 's'? Sono persone o persone? Quando lavori su un progetto con team di grandi dimensioni, questo può diventare un problema. Ad esempio, un'istanza in cui un membro del team utilizza il metodo errato per pluralizzare una tabella che crea. Quando interagisco con questa tabella, viene utilizzata dappertutto nel codice a cui non ho accesso o che richiederebbe troppo tempo per la correzione. Il risultato è che devo ricordare di aver sbagliato a scrivere la tabella ogni volta che la uso. Mi è successo qualcosa di molto simile a questo. Più è facile per ogni membro del team utilizzare in modo coerente e semplice l'esatto, correggere i nomi delle tabelle senza errori o cercare sempre i nomi delle tabelle, meglio è. La versione singolare è molto più semplice da gestire in un ambiente di squadra.

2. Se si utilizza la versione singolare del nome di una tabella E il prefisso della chiave primaria con il nome della tabella, ora si ha il vantaggio di determinare facilmente un nome di tabella da una chiave primaria o viceversa solo tramite il codice. Puoi ricevere una variabile con un nome di tabella, concatenare "Id" fino alla fine e ora hai la chiave primaria della tabella tramite codice, senza dover eseguire una query aggiuntiva. Oppure puoi tagliare "Id" dalla fine di una chiave primaria per determinare il nome di una tabella tramite codice. Se si utilizza "id" senza un nome di tabella per la chiave primaria, non è possibile tramite il codice determinare il nome della tabella dalla chiave primaria. Inoltre, la maggior parte delle persone che pluralizzano nomi di tabelle e prefissi colonne PK con il nome della tabella utilizzano la versione singolare del nome della tabella nel PK (ad esempio status e status_id),

3. Se rendi singolari i nomi delle tabelle, puoi farli corrispondere ai nomi delle classi che rappresentano. Ancora una volta, questo può semplificare il codice e consentirti di fare cose davvero ordinate, come creare un'istanza di una classe non avendo nient'altro che il nome della tabella. Inoltre, rende il codice più coerente, il che porta a ...

4. Se rendi singolare il nome della tabella, il tuo schema di denominazione sarà coerente, organizzato e facile da mantenere in ogni posizione. Sai che in ogni istanza nel tuo codice, sia che si tratti di un nome di colonna, come un nome di classe o come il nome della tabella, è lo stesso nome esatto. Ciò consente di eseguire ricerche globali per vedere ovunque vengano utilizzati i dati. Quando si plurale un nome di tabella, ci saranno casi in cui si utilizzerà la versione singolare di quel nome di tabella (la classe in cui si trasforma, nella chiave primaria). Ha senso non avere alcuni casi in cui i tuoi dati vengono definiti plurali e alcuni casi singolari.

Per riassumere, se si pluralizzano i nomi delle tabelle si stanno perdendo tutti i tipi di vantaggi nel rendere il codice più intelligente e più facile da gestire. Ci possono anche essere casi in cui devi avere tabelle / array di ricerca per convertire i nomi delle tue tabelle in oggetti o nomi di codici locali che potresti aver evitato. I nomi di tabelle singolari, sebbene all'inizio possano sembrare un po 'strani, offrono vantaggi significativi rispetto ai nomi pluralizzati e credo che siano le migliori pratiche.

la nostra preferenza:

1. I nomi delle tabelle dovrebbero essere plurali?
   Mai. Gli argomenti per cui si tratta di una raccolta hanno un senso, ma non si sa mai cosa conterrà la tabella (0,1 o molti articoli). Le regole plurali rendono inutilmente complicata la denominazione. 1 casa, 2 case, mouse contro topi, persona contro persone, e non abbiamo nemmeno guardato altre lingue.

   Update person set property = 'value'agisce su ogni persona nella tabella.
   Select * from person where person.name = 'Greg'restituisce una raccolta / set di righe di righe di persone.

2. I nomi delle colonne dovrebbero essere singolari?
   Di solito sì, tranne dove stai infrangendo le regole di normalizzazione.

3. Devo anteporre tabelle o colonne?
   Principalmente una preferenza di piattaforma. Preferiamo aggiungere il prefisso alle colonne con il nome della tabella. Non facciamo prefisso tabelle, ma facciamo prefisso viste (v_) e stored_procedures (sp_ o f_ (funzione)). Ciò aiuta le persone che vogliono provare a aggiornare v_person.age che in realtà è un campo calcolato in una vista (che non può essere comunque AGGIORNATO).

   È anche un ottimo modo per evitare la collisione delle parole chiave (delivery.from si rompe, ma delivery_from no).

   Rende il codice più dettagliato, ma spesso aiuta nella leggibilità.

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... è molto leggibile ed esplicito. Questo può sfuggire di mano però:

   customer.customer_customer_type_id

   indica una relazione tra cliente e la tabella customer_type, indica la chiave primaria nella tabella customer_type (customer_type_id) e se si vede mai 'customer_customer_type_id' durante il debug di una query, si sa immediatamente da dove proviene (tabella del cliente).

   o dove hai una relazione MM tra customer_type e customer_category (solo alcuni tipi sono disponibili per determinate categorie)

   customer_category_customer_type_id

   ... è un po '(!) sul lato lungo.

4. Dovrei usare un caso per nominare gli articoli? Sì - lettere minuscole :), con caratteri di sottolineatura. Questi sono molto leggibili e multipiattaforma. Insieme a 3 sopra ha anche senso.

   La maggior parte di questi sono preferenze però. - Fintanto che sei coerente, dovrebbe essere prevedibile per chiunque debba leggerlo.

Dai un'occhiata a ISO 11179-5: Nomi e principi di identificazione Puoi ottenerlo qui: http://metadata-standards.org/11179/#11179-5

Ne ho parlato nel blog qualche tempo fa: Convenzioni di denominazione ISO-11179

So che questo è in ritardo al gioco, e alla domanda è già stata data una risposta molto buona, ma voglio offrire la mia opinione su # 3 per quanto riguarda il prefisso dei nomi delle colonne.

Tutte le colonne devono essere denominate con un prefisso univoco per la tabella in cui sono definite.

Ad esempio, date le tabelle "cliente" e "indirizzo", andiamo rispettivamente con i prefissi di "cust" e "addr". "cliente" avrebbe "cust_id", "cust_name", ecc. al suo interno. "address" avrebbe "addr_id", "addr_cust_id" (FK torna al cliente), "addr_street", ecc. in esso.

Quando mi è stato presentato per la prima volta questo standard, sono stato messo a dura prova contro di esso; Ho odiato l'idea. Non potevo sopportare l'idea di tutta quella digitazione e ridondanza in più. Ora ho avuto abbastanza esperienza con esso che non ci tornerò mai più.

Il risultato è che tutte le colonne nello schema del database sono uniche. C'è un grande vantaggio in questo, che vince su tutti gli argomenti (a mio avviso, ovviamente):

Puoi effettuare ricerche nell'intera base di codici e trovare in modo affidabile ogni riga di codice che tocca una determinata colonna.

Il vantaggio del n. 1 è incredibilmente enorme. Posso deprecare una colonna e sapere esattamente quali file devono essere aggiornati prima che la colonna possa essere rimossa in modo sicuro dallo schema. Posso cambiare il significato di una colonna e sapere esattamente quale codice deve essere refactored. Oppure posso semplicemente dire se i dati di una colonna vengono persino utilizzati in una particolare porzione del sistema. Non posso contare il numero di volte in cui questo ha trasformato un progetto potenzialmente enorme in un progetto semplice, né la quantità di ore che abbiamo risparmiato nel lavoro di sviluppo.

Un altro vantaggio relativamente minore è che devi usare solo alias di tabella quando esegui un self join:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

Le mie opinioni su questi sono:

1) No, i nomi delle tabelle dovrebbero essere singolari.

Mentre sembra avere senso per la selezione semplice ( select * from Orders) ha meno senso per l'equivalente OO ( Orders x = new Orders).

Una tabella in un DB è davvero l'insieme di quell'entità, ha più senso una volta che si utilizza set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

L'ultima riga, l'attuale logica del join, sembra confusa con nomi di tabelle plurali.

Non sono sicuro di usare sempre un alias (come suggerisce Matt) lo chiarisce.

2) Dovrebbero essere singolari poiché contengono solo 1 proprietà

3) Mai, se il nome della colonna è ambiguo (come sopra, dove entrambi hanno una colonna chiamata [Chiave]), il nome della tabella (o il suo alias) può distinguerli abbastanza bene. Desideri che le query siano veloci da digitare e semplici: i prefissi aggiungono complessità non necessaria.

4) Qualunque cosa tu voglia, suggerirei CapitalCase

Non credo che ci sia una serie di linee guida assolute su nessuna di queste.

Fintanto che qualunque cosa tu scelga sia coerente tra l'applicazione o il DB, non penso che sia davvero importante.

Secondo me:

1. I nomi delle tabelle dovrebbero essere al plurale.
2. I nomi delle colonne dovrebbero essere singolari.
3. No.
4. CamelCase (il mio preferito) o underscore_separated sia per i nomi delle tabelle che per quelli delle colonne.

Tuttavia, come è stato menzionato, qualsiasi convenzione è meglio di nessuna convenzione. Non importa come scegli di farlo, documentalo in modo che le future modifiche seguano le stesse convenzioni.

Penso che la migliore risposta a ciascuna di queste domande sarebbe stata data da te e dal tuo team. È molto più importante avere una convenzione di denominazione piuttosto che esattamente la convenzione di denominazione è.

Poiché non esiste una risposta corretta a ciò, dovresti prenderti un po 'di tempo (ma non troppo) e scegliere le tue convenzioni e - ecco la parte importante - attenersi ad essa.

Ovviamente è bene cercare alcune informazioni sugli standard in merito, che è quello che stai chiedendo, ma non preoccuparti o preoccuparti del numero di diverse risposte che potresti ottenere: scegli quella che ti sembra migliore.

Per ogni evenienza, ecco le mie risposte:

1. Sì. Un tavolo è un gruppo di dischi , insegnanti o attori , quindi ... al plurale.
2. Sì.
3. Non li uso.
4. Il database che utilizzo più spesso - Firebird - mantiene tutto in maiuscolo, quindi non importa. Ad ogni modo, quando sto programmando scrivo i nomi in modo che sia più facile da leggere, come releaseYear .

1. Sicuramente mantenere i nomi delle tabelle singolari, persona non persone
   2. Anch'io
   3. No. Ho visto alcuni terribili prefissi, arrivando al punto di affermare che cosa stava trattando è una tabella (tbl_) o una procedura di archivio utente (usp_). Questo è seguito dal nome del database ... Non farlo!
   4. Sì. Tendo a PascalCase tutti i nomi delle mie tabelle

Le convenzioni di denominazione consentono al team di sviluppo di progettare la rilevabilità e la manutenibilità al centro del progetto.

Una buona convenzione di denominazione richiede tempo per evolversi, ma una volta in atto consente al team di andare avanti con un linguaggio comune. Una buona convenzione di denominazione cresce organicamente con il progetto. Una buona convenzione di denominazione affronta facilmente le modifiche durante la fase più lunga e importante del ciclo di vita del software: gestione dei servizi in produzione.

Ecco le mie risposte:

1. Sì, i nomi delle tabelle dovrebbero essere plurali quando si riferiscono ad una serie di operazioni , titoli o controparti per esempio.
2. Sì.
3. Sì. Le tabelle SQL hanno il prefisso tb_, le viste hanno il prefisso vw_, le procedure memorizzate hanno il prefisso usp_ e i trigger hanno il prefisso tg_ seguito dal nome del database.
4. Il nome della colonna deve essere minuscolo separato da un trattino basso.

La denominazione è difficile ma in ogni organizzazione c'è qualcuno che può nominare le cose e in ogni team di software dovrebbe esserci qualcuno che si assume la responsabilità degli standard di denominazione e garantisce che i problemi di denominazione come sec_id , sec_value e security_id vengano risolti presto prima che vengano inseriti nel progetto .

Quindi quali sono i principi di base di una buona convenzione e standard di denominazione: -

• Usa la lingua del tuo client e il dominio della tua soluzione
• Sii descrittivo
• Sii coerente
• Disambiguare, riflettere e riflettere
• Non usare abbreviazioni a meno che non siano chiare a tutti
• Non utilizzare parole chiave riservate SQL come nomi di colonna

Ecco un link che offre alcune opzioni. Stavo cercando una specifica semplice che potevo seguire piuttosto che dover fare affidamento su una parzialmente definita.

http://justinsomnia.org/writings/naming_conventions.html

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

I nomi delle tabelle dovrebbero essere sempre singolari, perché rappresentano un insieme di oggetti. Come dici tu branco di designare un gruppo di pecore, o gregge designare un gruppo di uccelli. Non è necessario il plurale. Quando un nome di tabella è composto da due nomi e la convenzione di denominazione è al plurale, diventa difficile sapere se il nome del plurale debba essere la prima parola o la seconda parola o entrambi. È la logica - Object.instance, non objects.instance. Oppure TableName.column, non TableNames.column (s). Microsoft SQL non fa distinzione tra maiuscole e minuscole, è più semplice leggere i nomi delle tabelle, se vengono utilizzate lettere maiuscole, per separare i nomi di tabelle o colonne quando sono composti da due o più nomi.

Nome tabella: dovrebbe essere singolare, in quanto è un'entità singolare che rappresenta un oggetto del mondo reale e non oggetti, che è singolare.

Nome colonna: dovrebbe essere singolare solo dopo che trasmette che avrà un valore atomico e confermerà la teoria della normalizzazione. Se tuttavia, ci sono n numero dello stesso tipo di proprietà, allora dovrebbero essere suffissi 1, 2, ..., n, ecc.

Prefisso tabelle / colonne: è un argomento enorme, che verrà discusso più avanti.

Involucro: dovrebbe essere il caso del cammello

Mio amico, Patrick Karcher , ti chiedo per favore di non scrivere nulla che possa essere offensivo per qualcuno, come hai scritto, "• Inoltre, le chiavi esterne devono essere nominate in modo coerente in tabelle diverse. Dovrebbe essere legale picchiare qualcuno che non lo fa Fai questo.". Non ho mai fatto questo errore, amico mio Patrick, ma scrivo in generale. E se hanno in programma di batterti per questo? :)

Molto tardi alla festa, ma volevo ancora aggiungere i miei due centesimi sui prefissi delle colonne

Sembrano esserci due argomenti principali per l'utilizzo dello standard di denominazione table_column (o tableColumn) per le colonne, entrambi basati sul fatto che il nome della colonna stessa sarà univoco nell'intero database:

1) Non è necessario specificare sempre nomi di tabella e / o alias di colonna nelle query

2) Puoi facilmente cercare l'intero codice per il nome della colonna

Penso che entrambi gli argomenti siano imperfetti. La soluzione per entrambi i problemi senza utilizzare i prefissi è semplice. Ecco la mia proposta:

Usa sempre il nome della tabella nel tuo SQL. Ad esempio, utilizzare sempre table.column anziché la colonna.

Risolve ovviamente 2) poiché ora puoi solo cercare table.column anziché table_column.

Ma posso sentirti urlare, come risolve 1)? Si trattava esattamente di evitare questo. Sì, lo era, ma la soluzione era orribilmente imperfetta. Perché? Bene, la soluzione del prefisso si riduce a:
Per evitare di dover specificare table.column quando c'è ambiguità, dai un nome a tutte le tue colonne table_column!
Ma questo significa che d'ora in poi dovrai SEMPRE scrivere il nome della colonna ogni volta che specifichi una colonna. Ma se devi farlo comunque, qual è il vantaggio di scrivere sempre table.column in modo esplicito? Esatto, non ci sono vantaggi, è lo stesso numero esatto di caratteri da digitare.

modifica: sì, sono consapevole che la denominazione delle colonne con il prefisso impone l'utilizzo corretto mentre il mio approccio si basa sui programmatori

Convenzioni di denominazione (e stile) del database essenziale (fare clic qui per una descrizione più dettagliata)

i nomi delle tabelle scelgono nomi brevi e non ambigui, l'uso di non più di una o due parole per distinguere le tabelle facilita facilmente la denominazione di nomi di campi univoci così come la ricerca e il collegamento delle tabelle dà alle tabelle nomi singolari, mai plurali (aggiornamento: sono ancora d'accordo con i motivi indicati per questa convenzione, ma alla maggior parte delle persone piacciono molto i nomi di tabella plurale, quindi ho ammorbidito la mia posizione) ... segui il link sopra per favore

I nomi delle tabelle sono singolari. Diciamo che stavi modellando una realtà tra qualcuno e il suo indirizzo. Ad esempio, se stai leggendo un modello di dati preferiresti "ogni persona può vivere a 0,1 o più indirizzi". o "ogni persona può vivere a 0,1 o più indirizzi". Penso che sia più facile pluralizzare l'indirizzo, piuttosto che riformulare le persone come persona. Inoltre i nomi collettivi sono abbastanza spesso dissimili alla versione singolare.

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Queste sono le convenzioni che mi hanno insegnato, ma dovresti adattarti a qualunque cosa usi il tubo flessibile di sviluppo.

1. Plurale. È una raccolta di entità.
2. Sì. L'attributo è una rappresentazione della proprietà singolare di un'entità.
3. Sì, il nome della tabella dei prefissi consente una denominazione facilmente tracciabile di tutti gli indici dei vincoli e gli alias delle tabelle.
4. Pascal Case per nomi di tabelle e colonne, prefisso + ALL maiuscole per indici e vincoli.