Schema di denominazione della chiave esterna

Ho appena iniziato a lavorare con le chiavi esterne per la prima volta e mi chiedo se esiste uno schema di denominazione standard da utilizzare per loro?

Date queste tabelle:

task (id, userid, title)
note (id, taskid, userid, note);
user (id, name)

Laddove le attività hanno note, le attività sono di proprietà degli utenti e le note degli autori degli utenti.

Come si chiamerebbero le tre chiavi esterne in questa situazione? Oppure, in alternativa, lo fa anche importa a tutti ?

Aggiornamento : questa domanda riguarda i nomi delle chiavi esterne, non i nomi dei campi!

La convenzione standard in SQL Server è:

FK_ForeignKeyTable_PrimaryKeyTable

Quindi, ad esempio, la chiave tra note e attività sarebbe:

FK_note_task

E la chiave tra attività e utenti sarebbe:

FK_task_user

Questo ti dà una visione 'a colpo d'occhio' di quali tabelle sono coinvolte nella chiave, quindi rende facile vedere da quali tabelle una particolare (la prima con nome) dipende (la seconda con nome). In questo scenario il set completo di chiavi sarebbe:

FK_task_user
FK_note_task
FK_note_user

Quindi puoi vedere che le attività dipendono dagli utenti e le note dipendono sia dalle attività che dagli utenti.

Uso due caratteri di sottolineatura come delimitatore, ad es

fk__ForeignKeyTable__PrimaryKeyTable 

Questo perché i nomi delle tabelle conterranno occasionalmente caratteri di sottolineatura stessi. Ciò segue la convenzione di denominazione per i vincoli in genere perché i nomi degli elementi di dati conterranno frequentemente caratteri di sottolineatura, ad es

CREATE TABLE NaturalPersons (
   ...
   person_death_date DATETIME, 
   person_death_reason VARCHAR(30) 
      CONSTRAINT person_death_reason__not_zero_length
         CHECK (DATALENGTH(person_death_reason) > 0), 
   CONSTRAINT person_death_date__person_death_reason__interaction
      CHECK ((person_death_date IS NULL AND person_death_reason IS NULL)
              OR (person_death_date IS NOT NULL AND person_death_reason IS NOT NULL))
        ...

Che ne dici FK_TABLENAME_COLUMNNAME?

K eep I t S Imple S tupid quando possibile.

Una nota di Microsoft relativa a SQL Server:

Un vincolo FOREIGN KEY non deve essere collegato solo a un vincolo PRIMARY KEY in un'altra tabella; può anche essere definito per fare riferimento alle colonne di un vincolo UNIQUE in un'altra tabella.

quindi, userò i termini che descrivono la dipendenza anziché i termini convenzionali di relazione primaria / estera.

Quando si fa riferimento al PRIMARY KEY della tabella indipendente (padre) dalle colonne con nomi simili nella tabella dipendente (figlio) , ometto i nomi di colonna:

FK_ChildTable_ParentTable

Quando si fa riferimento ad altre colonne, oppure i nomi delle colonne variano tra le due tabelle, o solo per essere espliciti:

FK_ChildTable_childColumn_ParentTable_parentColumn

Di solito lascio solo il mio ID nome PK e quindi concateno il nome della mia tabella e il nome della colonna chiave quando assegno gli FK in altre tabelle. Non mi preoccupo mai dell'involucro del cammello, perché alcuni database scartano la distinzione tra maiuscole e minuscole e restituiscono comunque tutti i nomi in maiuscolo o minuscolo. In ogni caso, ecco come sarebbe la mia versione dei tuoi tavoli:

task (id, userid, title);
note (id, taskid, userid, note);
user (id, name);

Nota che desidero anche nominare le mie tabelle al singolare, perché una riga rappresenta uno degli oggetti che sto persistendo. Molte di queste convenzioni sono preferenze personali. Suggerirei che è più importante scegliere una convenzione e usarla sempre, piuttosto che adottare la convenzione di qualcun altro.

Questo è probabilmente un over-kill, ma funziona per me. Mi aiuta molto quando ho a che fare soprattutto con i VLDB. Io uso il seguente:

CONSTRAINT [FK_ChildTableName_ChildColName_ParentTableName_PrimaryKeyColName]

Naturalmente se per qualche motivo non si fa riferimento a una chiave primaria, si deve fare riferimento a una colonna contenuta in un vincolo univoco, in questo caso:

CONSTRAINT [FK_ChildTableName_ChildColumnName_ParentTableName_ColumnInUniqueConstaintName]

Può essere lungo, sì. Ha aiutato a mantenere chiare le informazioni per i rapporti, o mi ha fatto fare un salto veloce sul fatto che il potenziale problema è durante un avvertimento al 100% che piacerebbe conoscere i pensieri delle persone su questa convenzione di denominazione.

Il mio solito approccio è

FK_ColumnNameOfForeignKey_TableNameOfReference_ColumnNameOfReference

O in altri termini

FK_ChildColumnName_ParentTableName_ParentColumnName

In questo modo posso nominare due chiavi esterne che fanno riferimento allo stesso tavolo come un history_info tablecon column actionBy and actionToda users_infotavolo

Sarà come

FK_actionBy_usersInfo_name - For actionBy
FK_actionTo_usersInfo_name - For actionTo

Nota che:

Non ho incluso il nome della tabella del bambino perché mi sembra di buon senso, sono nella tabella del bambino in modo da poter facilmente assumere il nome della tabella del bambino. Il personaggio totale è 26 e si adatta bene al limite dell'oracolo di 30 caratteri che è stato dichiarato da Charles Burns su un commento qui

Nota per i lettori: molte delle migliori pratiche elencate di seguito non funzionano in Oracle a causa del limite di 30 caratteri. Un nome di tabella o di colonna potrebbe essere già vicino a 30 caratteri, quindi una convenzione che combina i due in un singolo nome richiede uno standard di troncamento o altri trucchi. - Charles Burns

In base alle risposte e ai commenti qui, una convenzione di denominazione che include la tabella FK, il campo FK e la tabella PK (FK_FKTbl_FKCol_PKTbl) dovrebbe evitare le collisioni del nome del vincolo FK.

Quindi, per le tabelle fornite qui:

fk_task_userid_user
fk_note_userid_user

Quindi, se aggiungi una colonna per tenere traccia dell'ultima modifica di un'attività o una nota ...

fk_task_modifiedby_user
fk_note_modifiedby_user

Se non fai riferimento a questi FK così spesso e stai usando MySQL (e InnoDB), allora puoi semplicemente lasciare che MySQL nomini l'FK per te.

In un secondo momento è possibile trovare il nome FK necessario eseguendo una query .

Prova a usare l'UUID versione 4 maiuscolo con il primo ottetto sostituito da FK e '_' (trattino basso) invece di '-' (trattino).

Per esempio

• FK_4VPO_K4S2_A6M1_RQLEYLT1VQYV
• FK_1786_45A6_A17C_F158C0FB343E
• FK_45A5_4CFA_84B0_E18906927B53

La logica è la seguente

• Algoritmo di generazione rigorosa => nomi uniformi ;
• La lunghezza della chiave è inferiore a 30 caratteri , ovvero la limitazione della lunghezza dei nomi in Oracle (prima del 12c);
• Se il nome dell'entità cambia , non è necessario rinominare l'FK come nell'approccio basato sul nome dell'entità (se DB supporta l'operatore di rinomina tabella);
• Raramente si usa il nome del vincolo di chiave esterna. Ad esempio, lo strumento DB di solito mostra a cosa si applica il vincolo. Non c'è bisogno di aver paura dell'aspetto criptico, perché puoi evitare di usarlo per la "decodifica".