Database, una Tabella e di Colonna Convenzioni di Denominazione?[chiuso]

https://stackoverflow.com/questions/7662

08-06-2019
|

Domanda

Ogni volta che ho la progettazione di un database, mi chiedo sempre se c'è un modo migliore di denominazione di un prodotto nel mio database.Molto spesso mi pongo le seguenti domande:

Dovrebbe nomi di tabella di essere plurale?
Dovrebbe colonna nomi singolari?
Devo prefisso delle tabelle o colonne?
Devo usare ogni caso nella denominazione di oggetti?

Ci sono linee guida consigliate per denominazione voci di un database?

Soluzione

Vi consiglio di verificare di Microsoft SQL Server database di esempio:https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

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

I nomi singolari per le tabelle
I nomi singolari per le colonne
Nome di Schema per prefisso tabelle (E. g.:SchemeName.TableName)
Pascal (un.k.un.superiore camel)

Altri suggerimenti

Ritardo di risposta qui, ma in breve:

Il mio preferenza è plurale
Sì
Tavoli:*Di solito* non è prefissi è il migliore. Colonne:No.
Entrambe le tabelle e le colonne:PascalCase.

Elaborazione:

(1) Cosa si deve fare. Ci sono poche cose che si deve fare un certo modo, ogni volta, ma ci sono alcuni.

Il tuo nome le chiavi primarie l'utilizzo di "[singularOfTableName]ID" formato.Che è, se il nome della tabella è Cliente o I clienti, la chiave primaria deve essere CustomerID.
Inoltre, chiavi esterne deve essere chiamato in modo coerente in tabelle diverse.Dovrebbe essere legale per battere qualcuno che non.Io sarei del parere che, mentre definiti i vincoli di chiave esterna sono spesso importante, coerente chiave esterna di denominazione è sempre importante
È il database deve avere interna convenzioni.Anche se nelle sezioni successive, mi vedrete di essere molto flessibile, all'interno un database di denominazione deve essere molto coerente .Se il vostro tavolo per i clienti è chiamato I clienti o Cliente è meno importante che lo si fa allo stesso modo in tutto il database stesso.E si può lanciare una moneta per determinare come utilizzare il carattere di sottolineatura, ma poi si deve continuare a usare il loro stesso modo.Se non fai questo, tu sei una persona cattiva, che dovrebbe avere una bassa autostima.

(2) Che cosa si dovrebbe probabilmente fare.

Campi, che rappresenta lo stesso tipo di dati in tabelle diverse dovrebbe avere lo stesso nome.Non hai Zip in una tabella e Il codice postale di un altro.
Per separare le parole in una tabella o di nomi di colonna, utilizzare PascalCasing.Utilizzando camelCasing non sarebbe intrinsecamente problematico, ma non la convenzione e il risultato sarebbe divertente.Rivolgo sottolinea in un attimo.(Non si possono utilizzare ALLCAPS come nei vecchi giorni.OBNOXIOUSTABLE.ANNOYING_COLUMN è stato bene in DB2 20 anni fa, ma non ora.)
Non artifically accorciare o abbreviare le parole.E ' meglio per un nome lungo e chiaro di una breve e confusa.Ultra-breve i nomi è un retaggio più scuro, più selvaggio volte.Cus_AddRef.Che diavolo è?Custodia Destinatario Di Riferimento?Cliente Un Ulteriore Rimborso?Indirizzo Personalizzato Rinvio?

(3) Che cosa si dovrebbe prendere in considerazione.

Credo davvero che si dovrebbe avere nomi plurali tabelle;alcuni pensano singolare.Leggere gli argomenti che altrove.I nomi di colonna deve essere singolare, tuttavia.Anche se si usa il plurale dei nomi di tabella, tabelle che rappresentano combinazioni di altri tavoli potrebbero essere al singolare.Per esempio, se si dispone di un Promozioni e un Articoli tavola, che rappresenta un elemento di essere parte di una promozione potrebbe essere Promotions_Items, ma potrebbe anche essere legittimamente Promotion_Items penso che rispecchiano l'uno-a-molti rapporto).
Utilizzare sottolinea costantemente e per un particolare scopo.Generale nomi di tabelle dovrebbe essere abbastanza chiaro con PascalCasing;non hai bisogno di trattini per separare le parole.Risparmiare caratteri di sottolineatura (a) per indicare un associativo tabella o (b) per il prefisso, che rivolgo al punto successivo.
Il prefisso non è né buona né cattiva.Si di solito non è la migliore.Nel tuo primo db o due, non vorrei suggerire l'uso di prefissi per tematiche generali di raggruppamento di tabelle.Tabelle di non finire di montare le categorie facilmente, e si può effettivamente fare più difficile per trovare tabelle.Con l'esperienza, è possibile pianificare e applicare un prefisso schema che fa più bene che male.Ho lavorato in un db una volta in cui le tabelle di dati è iniziata con tbl, configurazione tabelle con ctbl, vista con vew, proc s sp, e udf fn, e pochi altri;è stato meticolosamente, applicati in modo coerente in modo ha funzionato bene.L'unica volta che è NECESSARIO prefissi è quando hai davvero separare le soluzioni che per qualche motivo si trovano nella stessa db;loro prefisso può essere molto utile nel raggruppare le tabelle.Il prefisso va bene anche per situazioni particolari, come per le tabelle temporanee che si vuole distinguersi.
Molto raramente (se non mai) che si desidera prefisso colonne.

Ok, dato che siamo di pesatura con il parere:

Credo che i nomi delle tabelle deve essere plurale.Le tabelle sono una raccolta (una tabella) di entità.Ogni riga rappresenta una singola entità, e la tabella rappresenta la raccolta.Così mi avrebbe chiamata una tabella di entità Persona le Persone (o le Persone, qualunque prende la vostra fantasia).

Per coloro che amano vedere singolare "nomi di entità" nelle query, che è quello che vorrei utilizzare gli alias di tabella per:

SELECT person.Name
FROM People person

Un po ' come LINQ "da persona a persone selezionate la persona.Nome".

Come per il 2, 3 e 4, sono d'accordo con @Lars.

Io lavoro in un database team di supporto con tre amministratori di database e le nostre opzioni sono:

Qualsiasi standard di denominazione è meglio di no standard.
Non c'è nessun "vero" standard, tutti abbiamo le nostre preferenze
Se c'è standard già in uso, utilizzare.Non creare un altro standard o fangoso le norme esistenti.

Usiamo i nomi singolari per le tabelle.Tabelle tendono a essere preceduto dal nome del sistema (o il suo acronimo).Questo è utile se il vostro sistema complesso come è possibile modificare il prefisso per il gruppo le tabelle insieme logicamente (ie.reg_customer, reg_booking e regadmin_limits).

Per i campi ci si aspetterebbe che i nomi dei campi da includere il prefisso/acryonm della tabella (es.cust_address1) e anche noi preferiscono l'uso di un set standard di suffissi ( _id per il PK, _cd per "codice", _nm per "nome", _nb per il "numero", _dt per "Data").

Il nome del Foriegn campo chiave dovrebbe essere lo stesso come il campo chiave Primaria.

cioè

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

Quando lo sviluppo di un nuovo progetto, mi consiglia di scrivere tutti i preferito nomi di entità, prefissi e degli acronimi e dare a questo documento per gli sviluppatori.Quindi, quando si decide di creare una nuova tabella, si può fare riferimento al documento piuttosto che di "indovinare" quello che la tabella e i campi devono essere chiamati.

No.Una tabella deve essere chiamato dopo che l'ente che rappresenta.Persona, persone non è come vorresti riferisco a uno dei record rappresenta.
Di nuovo, stessa cosa.La colonna Nome in realtà non dovrebbe essere chiamato FirstNames.Tutto dipende da cosa si vuole rappresentare con la colonna.
NO.
Sì.Caso per chiarezza.Se hai bisogno di avere le colonne come "Nome", telaio renderà più facile la lettura.

Ok.Questo è il mio $0.02

Anche io sono a favore di una ISO/IEC 11179 stile di denominazione convenzione, visto che sono le linee guida piuttosto che essere prescrittivo.

Vedere Elemento di dati nome su Wikipedia:

"I tavoli sono Insiemi di Entità, e seguire la Raccolta di linee guida di denominazione.Idealmente, un nome collettivo è utilizzato:es., Personale.Il plurale è anche corretto:Dipendenti.Nomi non corretti sono:Dipendente, tblEmployee, e EmployeeTable."

Come sempre, ci sono eccezioni alle regole, ad es.un tavolo che ha sempre esattamente una riga potrebbe essere meglio con un nome singolare per es.una configurazione della tabella.E la coerenza è della massima importanza:controllare se il negozio ha una convenzione e, se è così, seguire;se non ti piace poi fare un business case per cambiarla piuttosto che essere il lone ranger.

la nostra preferenza:

Dovrebbe nomi di tabella di essere plurale?
Mai.Gli argomenti per essere una raccolta di senso, ma non si sa mai che cosa il tavolo per contenere (0,1 o molti elementi).Plurale regole rendono la denominazione inutilmente complicato.1 Casa, 2 case, mouse vs topi, persona vs persone, e non abbiamo ancora guardato in tutte le altre lingue.

Update person set property = 'value' agisce su ogni persona in tabella.
Select * from person where person.name = 'Greg' restituisce una collezione/set di righe di persona righe.
Dovrebbe colonna nomi singolari?
Di solito, sì, tranne dove si stanno rompendo formula di normalizzazione.
Devo prefisso delle tabelle o colonne?
Soprattutto una piattaforma di preferenza.Preferiamo prefisso colonne con il nome della tabella.Non ci prefisso delle tabelle, ma noi prefisso vista (v_) e stored_procedures (sp_ o f_ (funzione)).Che aiuta le persone che vogliono provare a upday v_person.età che in realtà è un campo calcolato in una vista (che non può essere Aggiornata in ogni caso).

È anche un ottimo modo per evitare la parola chiave di collisione (consegna.da interruzioni, ma delivery_from non).

Non rendere il codice più dettagliato, ma spesso aids in leggibilità.

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

customer.customer_customer_type_id

indica una relazione tra il cliente e il tipo_cliente tabella, indica la chiave primaria nella tipo_cliente tabella (customer_type_id) e se avete mai visto 'customer_customer_type_id', mentre il debug di una query, si sa subito dove (tabella clienti).

o in cui si dispone di un M-M rapporto tra tipo_cliente e customer_category (solo alcuni tipi sono disponibili per alcune categorie)

customer_category_customer_type_id

...è un po' (!) sul lato lungo.
Devo usare ogni caso nella denominazione di oggetti?Sì - minuscole), con caratteri di sottolineatura.Questi sono molto leggibili e cross-platform.Insieme con i 3 di cui sopra ha anche senso.

La maggior parte di queste sono preferenze, però.- Si, purché coerenti, dovrebbe essere prevedibile per chiunque di leggere.

Ho sentito l'argomento per tutto il tempo che se una tabella è pluralizzata, è tutta una questione di gusto personale e non c'è la migliore pratica.Non credo che è vero, soprattutto come programmatore in contrapposizione a un DBA.Per quanto ne so, non ci sono motivi legittimi per creare il plurale dei nome di una tabella diversa da "rende solo senso per me perché è una collezione di oggetti", mentre ci sono legittimi guadagni in codice, avendo il singolare i nomi di tabella.Per esempio:

Evita di bug e di errori dovuti al plurale ambiguità.I programmatori non sono esattamente noti per la loro ortografia competenze, e pluralizing alcune parole sono fonte di confusione.Per esempio, la parola plurale finiscono in " es "o semplicemente "s'?È o persone?Quando si lavora su un progetto con grandi squadre, questo può diventare un problema.Per esempio, un caso in cui un membro del team utilizza il metodo corretto per creare il plurale dei una tabella che crea.Con il tempo ho interagire con questa tabella, è utilizzato in tutto nel codice non ho accesso o prendere tempo per risolvere.Il risultato è che devo ricordare di scrivere la tabella di male ogni volta che lo uso.Qualcosa di molto simile a questo è accaduto a me.Il più semplice si può fare per ogni membro della squadra costantemente e facilmente utilizzare esatto, corretto i nomi di tabella di assenza di errori o di dover cercare i nomi di tabella, per tutto il tempo, il migliore.La singolare versione è molto più facile da gestire in un ambiente della squadra.
Se si utilizza la singolare versione di un nome di tabella E il prefisso chiave primaria con il nome della tabella, si ha il vantaggio di facilmente determinare un nome di tabella una chiave primaria o viceversa tramite il codice da solo.Si può essere data una variabile con un nome di tabella in esso, è possibile concatenare "Id" alla fine, e ora avete la chiave primaria della tabella tramite codice, senza dover fare un'ulteriore query.Oppure si può tagliare "Id" dalla fine di una chiave primaria per determinare il nome di una tabella tramite il codice.Se si utilizza "id" senza un nome di tabella per la chiave primaria, quindi non è possibile tramite codice determinare il nome della tabella da chiave primaria.Inoltre, la maggior parte delle persone che creare il plurale dei nomi di tabella e il prefisso PK colonne con il nome della tabella uso il singolare versione del nome della tabella nel PK (per esempio gli stati e statusId), rendendo impossibile fare tutto questo.
Se si fanno i nomi di tabella singolare, è possibile abbinare i nomi delle classi che rappresentano.Ancora una volta, questo può semplificare il codice e permette di fare davvero cose carine, come creare un'istanza di una classe, non avendo nulla, ma il nome della tabella.Inoltre, rende il codice molto più consistente, che porta a...
Se si effettua il nome della tabella singolare, si rende il vostro schema di denominazione coerente, organizzato e facile da mantenere in ogni posizione.Si sa che in ogni caso nel codice, che sia in nome di una colonna, come un nome di classe, o il nome della tabella, è lo stesso nome esatto.Questo permette di fare ricerche globali per vedere ovunque che i dati utilizzati.Quando si creare il plurale dei un nome di tabella, ci saranno casi in cui si usa il singolare versione del nome della tabella (la classe si trasforma in, nella chiave primaria).Rende solo senso non sono alcuni casi in cui i dati di cui all'come il plurale e in alcuni casi singolari.

Per riassumere, se si creare il plurale dei vostri nomi di tabella, si stanno perdendo tutti i tipi di vantaggi in grado di rendere il codice più intelligente e più facile da gestire.Ci possono anche essere casi in cui si hanno tabelle di ricerca/matrici per convertire i nomi di tabella per oggetto o locale dei nomi in codice, si poteva evitare.Singolare i nomi di tabella, anche se forse sentendosi un po ' strano in un primo momento, offrono vantaggi significativi rispetto plurale di nomi e, credo, sono le migliori prassi.

Date un'occhiata a ISO 11179-5:Denominazione e identificazione principi Puoi trovare qui: http://metadata-standards.org/11179/#11179-5

Ho bloggato su di esso un po ' indietro qui: ISO-11179 Convenzioni di Denominazione

So che è tardi per il gioco, e la domanda ha ricevuto una risposta già molto bene, ma voglio offrire il mio parere su #3 per quanto riguarda il prefisso dei nomi di colonna.

Tutte le colonne devono essere denominati con un prefisso univoco della tabella sono definiti.

E. g.Dato tabelle "cliente" e "indirizzo", andiamo con i prefissi "cust" e "addr", rispettivamente."cliente" sarebbe "cust_id", "cust_name", etc.in esso."indirizzo" sarebbe "addr_id", "addr_cust_id" (FK indietro al cliente), "addr_street", etc.in esso.

Quando mi è stato presentato per la prima volta con questo standard, mi era morto insieme contro di essa;Ho odiato l'idea.Non riuscivo a sopportare l'idea di eccesso di digitazione e di ridondanza.Ora ho avuto abbastanza esperienza con esso, che non avevo mai tornare indietro.

Il risultato di questa operazione è che tutte le colonne nel database schema sono unici.C'è un importante vantaggio di questo, che trionfa su tutti gli argomenti contro di essa (a mio parere, ovviamente):

È possibile cercare la vostra intera base di codice e di individuare in modo affidabile ogni riga di codice che tocca una determinata colonna.

Il beneficio #1 è incredibilmente enorme.Posso deprecare una colonna e sapere esattamente quali file devono essere aggiornati prima che la colonna può essere tranquillamente rimosso dallo schema.Posso cambiare il significato di una colonna e di sapere esattamente che cosa il codice deve essere rielaborato.O posso semplicemente dire se i dati da una colonna è anche essere utilizzato in una particolare porzione del sistema.Non riesco a contare il numero di volte che questo ha trasformato un potenziale enorme progetto in un semplice, né la quantità di ore che abbiamo salvato nel lavoro di sviluppo.

Un altro, relativamente minore vantaggio è che è necessario utilizzare la tabella-alias quando si fa 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 di tabella deve essere singolare.

Mentre sembra avere un senso per il semplice selezione (select * from Orders) ha meno senso per le OO equivalente (Orders x = new Orders).

In una tabella di un DB è davvero il set di che entità, ha più senso una volta che si utilizza il set-logica:

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

Che l'ultima riga, la vera logica del join, sembra confondere con il plurale dei nomi di tabella.

Io non sono sicuro circa, sempre utilizzando un alias (come suggerisce Matt) chiarisce che fino.

2) dovrebbero essere singolare come tenere solo 1 struttura

3) Mai, se il nome della colonna è ambiguo (come sopra, dove entrambi hanno una colonna denominata [Chiave]) il nome della tabella (o il suo alias) li possa distinguere abbastanza bene.Vuoi query di essere veloce e di tipo semplice prefissi di aggiungere inutili complessità.

4) tutto quello che vuoi, io suggerirei di CapitalCase

Io non credo che ci sia un set di linee guida assoluti su uno di questi.

Come lungo come si sceglie è coerente in tutta l'applicazione o il DB non credo che conta davvero.

A mio parere:

I nomi di tabella deve essere plurale.
I nomi di colonna deve essere singolare.
No.
Sia CamelCase (il mio preferito) o underscore_separated sia per i nomi di tabella e di colonna nomi.

Tuttavia, come è stato detto, ogni convenzione è meglio di nessuna convenzione.Non importa come si sceglie di farlo, documento, in modo che le future modifiche seguire le stesse convenzioni.

Sicuramente tenere i nomi di tabella singolare, la persona, non le persone
1. Stesso qui
2. No.Ho visto alcune terribile prefissi, fino al punto di affermare ciò che aveva a che fare con una tabella (tbl_) o un utente di memorizzare procedure (usp_).Questo seguito dal nome del database...Non farlo!
3. Sì.Io tendo a PascalCase tutti i miei nomi di tabella

Io credo che la migliore risposta a ognuna di queste domande è data da voi e il vostro team.E ' molto più importante avere una convenzione di denominazione, quindi esattamente come la convenzione di denominazione.

Come non esiste una risposta giusta a quello, si dovrebbe prendere un po ' di tempo (ma non troppo) e scegliere le proprie convenzioni e ecco la parte importante - bastone ad esso.

Naturalmente è bene cercare un po ' di informazioni su norme che, che è quello che stai chiedendo, ma non diventano ansiosi o preoccupati per il numero di risposte diverse, si potrebbe ottenere:scegliere quello che sembra migliore per voi.

Solo nel caso, qui sono le mie risposte:

Sì.Una tabella è un gruppo di record, gli insegnanti o attori, è , quindi...il plurale.
Sì.
Io non li uso.
Il database che uso più spesso - Firebird - tiene tutto in maiuscolo, in modo che non importa.Comunque, quando mi trovo di programmazione scrivo i nomi in un modo che è facile da leggere, come releaseYear.

Convenzioni di denominazione consentire al team di sviluppo per la progettazione di discovereability e manutenibilità al centro del progetto.

Una buona convenzione di denominazione prende il tempo per evolvere, ma una volta che è in atto permette alla squadra di andare avanti con un linguaggio comune.Una buona convenzione di denominazione cresce organicamente con il progetto.Una buona convenzione di denominazione facilmente affronta con modifiche durante il più grande e più importante fase del ciclo di vita del software di gestione del servizio di produzione.

Ecco le mie risposte:

Sì, i nomi di tabella deve essere plurale, quando si riferisce a un insieme di mestieri, titoli, o controparti per esempio.
Sì.
Sì.Tabelle SQL sono preceduti tb_, viste sono precedute vw_, stored procedure sono precedute usp_ e trigger sono precedute tg_ seguita dal nome del database.
Nome della colonna deve essere inferiore, in caso separati da un carattere di sottolineatura.

La denominazione è difficile, ma in ogni organizzazione c'è qualcuno che può indicare le cose e in ogni squadra ci deve essere qualcuno che si prende la responsabilità di diciture standard e assicura che la denominazione di problemi come sec_id, sec_value e security_id ottenere risolta presto, prima che essi vengono cotti nel progetto.

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

Utilizzare il linguaggio del vostro client e la soluzione di dominio
Essere descrittivo
Essere coerenti
L'ambiguità, riflettere e rielaborare
Non usare le abbreviazioni a meno che sono chiari a tutti
Non utilizzare SQL riservato parole chiave come i nomi di colonna

Ecco un link che offre poche scelte.Ero alla ricerca di un semplice spec che ho potuto seguire, piuttosto che dover fare affidamento su un parzialmente definito.

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

I nomi di tabella deve essere sempre singolare, perché rappresentano un insieme di oggetti.Come dici branco, per designare un gruppo di pecore, gregge o fare designare un gruppo di uccelli.Nessuna necessità per il plurale.Quando un nome di tabella è la composizione di due nomi e la convenzione di denominazione è al plurale diventa difficile sapere se il nome plurale dovrebbe essere la prima parola o la seconda parola o entrambi.È la logica – Oggetto.istanza, non di oggetti.esempio.O TableName.colonna, non TableNames.colonna(s).Microsoft SQL non è case sensitive, è più facile leggere i nomi di tabella, se le lettere maiuscole sono utilizzati per separare la tabella o di nomi di colonna quando essi sono costituiti da due o più nomi.

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

Nome Tabella: Dovrebbe essere singolare, in quanto è una singolare entità che rappresenta un oggetto del mondo reale e non di oggetti, che è singlular.

Il Nome Di Colonna: Dovrebbe essere singolare, solo allora, si comunica che si terrà un valore atomico, e confermare la normalizzazione teoria.Se, tuttavia, ci sono n numero di stesso tipo di proprietà, allora si dovrebbe essere con il suffisso 1, 2, ..., n, ecc.

Come Prefisso Per Le Tabelle / Colonne:È un argomento enorme, parleremo dopo.

Involucro:Dovrebbe essere Camel

Il mio amico, Patrick Karcher, Chiedo, per piacere, non scrivere tutto ciò che può essere offensivo per qualcuno, come hai scritto, "•Ulteriore, chiavi esterne devono essere denominati in modo coerente nelle diverse tabelle.Dovrebbe essere legale per battere qualcuno che non la fanno.".Non ho mai fatto questo errore mio amico Patrick, ma sto scrivendo in genere.E se loro insieme il piano di battere per questo?:)

Molto in ritardo alla festa, ma volevo ancora aggiungere i miei due centesimi sulla colonna prefissi

Sembra che ci siano due argomenti principali per l'utilizzo del table_column (o tableColumn) denominazione standard per colonne, entrambi basati sul fatto che il nome della colonna stessa sarà unico in tutta la base di dati:

1) non È necessario specificare i nomi di tabella e/o alias di colonna nelle query per tutto il tempo

2) Si può facilmente cercare il codice completo per il nome della colonna

Penso che entrambi gli argomenti sono viziati.La soluzione ad entrambi i problemi senza l'uso di prefissi è facile.Ecco la mia proposta:

Utilizzare sempre il nome della tabella in SQL.E. g., sempre utilizzare la tabella.colonna invece di colonna.

Ovviamente risolve 2) come si può ora solo di ricerca per la tabella.colonna invece di table_column.

Ma io vi sento urlare, come fa a risolvere 1)?Proprio per evitare questo.Sì, lo era, ma la soluzione era terribilmente viziata.Perché?Beh, il prefisso soluzione si riduce a:
Per evitare di dover specificare la tabella.colonna quando c'è ambiguità, è il nome di colonne table_column!
Ma questo significa che da ora in poi SEMPRE scrivere il nome della colonna ogni volta specificare una colonna.Ma se devi farlo comunque, qual è il beneficio, sempre in modo esplicito tabella di scrittura.colonna?Esattamente, non c'è alcun beneficio, è lo stesso identico numero di caratteri da digitare.

edit:sì, sono consapevole del fatto che la denominazione di colonne con il prefisso impone l'utilizzo corretto considerando che il mio approccio si basa sui programmatori

Essenziale Convenzioni di Denominazione dei Database (e di Stile) (clicca qui per una descrizione più dettagliata)

i nomi di tabella scegliere di breve, nomi univoci, usando non più di una o due parole distinguere le tabelle facilmente facilita la denominazione unica di nomi di campo nonché di ricerca e di collegamento di tabelle dare tavoli i nomi singolari, mai plurale (aggiornamento:io ancora d'accordo con le ragioni di questa convenzione, ma la maggior parte delle persone piace molto il plurale dei nomi di tabella, quindi ho ammorbidito la mia posizione)...segui il link qui sopra, si prega di

I nomi di tabella singolare.Diciamo che sono state modellazione di un rapporto tra una persona e il loro indirizzo.Per esempio, se si sta leggendo un datamodel preferisci 'ogni persona possa vivere a 0,1 o molti di indirizzo.' o 'ogni popolo può vivere a 0,1 o molti indirizzi.' Penso che la sua più facile pluralise indirizzo, piuttosto che avere a riformulare la gente come persona.Plus nomi collettivi sono molto spesso dissimlar per la singolare versione.


--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 è stato insegnato, ma si dovrebbe adattare a qualunque cosa si sviluppo il tubo di usi.

Il plurale.Si tratta di un insieme di entità.
Sì.L'attributo è una rappresentazione della singolare proprietà di un'entità.
Sì, prefisso nome della tabella permette facilmente rintracciabile la denominazione di tutti i vincoli, gli indici e gli alias di tabella.
Pascal Caso di nomi di tabelle e colonne, prefisso + TUTTI i tappi per indici e vincoli.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow