Benennungsschema für Fremdschlüssel

Ich arbeite gerade zum ersten Mal mit Fremdschlüsseln und frage mich, ob es ein Standard-Namensschema für sie gibt.

Angesichts dieser Tabellen:

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

Wenn Aufgaben Notizen enthalten, gehören Aufgaben den Benutzern und Benutzer verfassen Notizen.

Wie würden die drei Fremdschlüssel in dieser Situation benannt? Oder spielt es überhaupt eine Rolle ?

Update : Bei dieser Frage geht es um Fremdschlüsselnamen, nicht um Feldnamen!

Die Standardkonvention in SQL Server lautet:

FK_ForeignKeyTable_PrimaryKeyTable

So wäre beispielsweise der Schlüssel zwischen Notizen und Aufgaben:

FK_note_task

Und der Schlüssel zwischen Aufgaben und Benutzern wäre:

FK_task_user

Auf diese Weise erhalten Sie auf einen Blick einen Überblick darüber, welche Tabellen am Schlüssel beteiligt sind. So können Sie leicht erkennen, von welchen Tabellen eine bestimmte (die erste benannte) (die zweite benannte) abhängt. In diesem Szenario wäre der vollständige Schlüsselsatz:

FK_task_user
FK_note_task
FK_note_user

So können Sie sehen, dass Aufgaben von Benutzern abhängen und Notizen sowohl von Aufgaben als auch von Benutzern abhängen.

Ich benutze zwei Unterstriche als Trennzeichen, dh

fk__ForeignKeyTable__PrimaryKeyTable 

Dies liegt daran, dass Tabellennamen gelegentlich selbst Unterstriche enthalten. Dies folgt im Allgemeinen der Namenskonvention für Einschränkungen, da die Namen von Datenelementen häufig Unterstriche enthalten, z

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))
        ...

Wie wäre es FK_TABLENAME_COLUMNNAME?

K eep I t S imple S tupid wann immer möglich.

Ein Hinweis von Microsoft zu SQL Server:

Eine FOREIGN KEY-Einschränkung muss nicht nur mit einer PRIMARY KEY-Einschränkung in einer anderen Tabelle verknüpft sein. Es kann auch definiert werden, um auf die Spalten einer UNIQUE-Einschränkung in einer anderen Tabelle zu verweisen.

Daher verwende ich Begriffe, die die Abhängigkeit beschreiben, anstelle der herkömmlichen Begriffe für primäre / fremde Beziehungen.

Wenn ich auf den PRIMARY KEY der unabhängigen (übergeordneten) Tabelle durch die ähnlich benannten Spalten in der abhängigen (untergeordneten) Tabelle verweise, lasse ich die Spaltennamen weg:

FK_ChildTable_ParentTable

Wenn Sie auf andere Spalten verweisen oder die Spaltennamen zwischen den beiden Tabellen variieren oder nur um explizit zu sein:

FK_ChildTable_childColumn_ParentTable_parentColumn

Normalerweise lasse ich einfach meine PK mit dem Namen id und verkette dann meinen Tabellennamen und den Namen der Schlüsselspalte, wenn ich FKs in anderen Tabellen benenne. Ich kümmere mich nie um Kamelhüllen, da einige Datenbanken die Groß- und Kleinschreibung verwerfen und trotzdem einfach alle Groß- oder Kleinbuchstaben zurückgeben. In jedem Fall würde meine Version Ihrer Tabellen folgendermaßen aussehen:

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

Beachten Sie, dass ich meine Tabellen auch im Singular benenne, da eine Zeile eines der Objekte darstellt, die ich beibehalten habe. Viele dieser Konventionen sind persönliche Vorlieben. Ich würde vorschlagen, dass es wichtiger ist, eine Konvention zu wählen und sie immer zu verwenden, als die Konvention eines anderen zu übernehmen.

Dies ist wahrscheinlich übertrieben, aber es funktioniert für mich. Es hilft mir sehr, wenn ich mich besonders mit VLDBs beschäftige. Ich benutze folgendes:

CONSTRAINT [FK_ChildTableName_ChildColName_ParentTableName_PrimaryKeyColName]

Wenn Sie aus irgendeinem Grund nicht auf einen Primärschlüssel verweisen, müssen Sie natürlich auf eine Spalte verweisen, die in einer eindeutigen Einschränkung enthalten ist. In diesem Fall:

CONSTRAINT [FK_ChildTableName_ChildColumnName_ParentTableName_ColumnInUniqueConstaintName]

Kann es lange dauern, ja. Hat es mir geholfen, Informationen für Berichte klar zu halten, oder hat es mir einen schnellen Einblick gegeben, dass das potenzielle Problem während eines Produktalarms besteht? 100% würden gerne die Gedanken der Menschen über diese Namenskonvention erfahren.

Mein üblicher Ansatz ist

FK_ColumnNameOfForeignKey_TableNameOfReference_ColumnNameOfReference

Oder anders ausgedrückt

FK_ChildColumnName_ParentTableName_ParentColumnName

Auf diese Weise kann ich zwei Fremdschlüssel benennen, die auf dieselbe Tabelle verweisen wie eine history_info tablewith column actionBy and actionTofrom- users_infoTabelle

Es wird so sein

FK_actionBy_usersInfo_name - For actionBy
FK_actionTo_usersInfo_name - For actionTo

Beachten Sie, dass:

Ich habe den Namen der untergeordneten Tabelle nicht angegeben, da es mir vernünftig erscheint. Ich bin in der Tabelle des Kindes, sodass ich den Tabellennamen des Kindes leicht annehmen kann. Der Gesamtcharakter ist 26 und passt gut zu der 30-Zeichen-Grenze von Orakel, die Charles Burns in einem Kommentar hier angegeben hat

Hinweis für Leser: Viele der unten aufgeführten Best Practices funktionieren in Oracle aufgrund der Beschränkung auf 30 Zeichen nicht. Ein Tabellenname oder Spaltenname kann bereits fast 30 Zeichen enthalten. Daher erfordert eine Konvention, bei der beide zu einem einzigen Namen kombiniert werden, einen Kürzungsstandard oder andere Tricks. - Charles Burns

Basierend auf den Antworten und Kommentaren hier sollte eine Namenskonvention, die die FK-Tabelle, das FK-Feld und die PK-Tabelle (FK_FKTbl_FKCol_PKTbl) enthält, Kollisionen von FK-Einschränkungsnamen vermeiden.

Also, für die angegebenen Tabellen hier:

fk_task_userid_user
fk_note_userid_user

Wenn Sie also eine Spalte hinzufügen, um zu verfolgen, wer zuletzt eine Aufgabe oder eine Notiz geändert hat ...

fk_task_modifiedby_user
fk_note_modifiedby_user

Wenn Sie nicht so oft auf Ihre FKs verweisen und MySQL (und InnoDB) verwenden, können Sie MySQL einfach die FK für Sie benennen lassen.

Zu einem späteren Zeitpunkt können Sie den gewünschten FK-Namen finden, indem Sie eine Abfrage ausführen .

Versuchen Sie, die UUID der Version 4 in Großbuchstaben zu verwenden, wobei das erste Oktett durch FK und '_' (Unterstrich) anstelle von '-' (Bindestrich) ersetzt wird.

Z.B

• FK_4VPO_K4S2_A6M1_RQLEYLT1VQYV
• FK_1786_45A6_A17C_F158C0FB343E
• FK_45A5_4CFA_84B0_E18906927B53

Begründung ist die folgende

• Strenger Generierungsalgorithmus => einheitliche Namen ;
• Die Schlüssellänge beträgt weniger als 30 Zeichen . Dies bedeutet eine Beschränkung der Namenslänge in Oracle (vor 12c).
• Wenn sich Ihr Entitätsname ändert, müssen Sie Ihre FK nicht umbenennen wie bei einem auf Entitätsnamen basierenden Ansatz umbenennen (wenn DB den Operator zum Umbenennen von Tabellen unterstützt).
• Man würde selten den Namen der Fremdschlüsseleinschränkung verwenden. Beispielsweise zeigt das DB-Tool normalerweise an, wofür die Einschränkung gilt. Sie müssen keine Angst vor einem kryptischen Aussehen haben, da Sie vermeiden können, es für die "Entschlüsselung" zu verwenden.