Frage Primärschlüssel / Fremdschlüssel Namenskonvention [geschlossen]


In unserer Dev-Gruppe haben wir eine heftige Debatte über die Namenskonvention für Primär- und Fremdschlüssel. Es gibt im Grunde zwei Denkrichtungen in unserer Gruppe:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

oder

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

Ich bevorzuge es, den Namen der Tabelle in keiner der Spalten zu duplizieren (also bevorzuge ich Option 1 oben). Konzeptionell entspricht es einer Vielzahl der empfohlenen Vorgehensweisen in anderen Sprachen, in denen Sie den Namen des Objekts nicht in seinen Eigenschaftsnamen verwenden. Ich denke, dass das Benennen des Fremdschlüssels EmployeeID (oder Employee_ID könnte besser sein) sagt dem Leser, dass es das ist ID Spalte der Employee Tabelle.

Einige andere bevorzugen die Option 2, bei der Sie den Primärschlüssel mit dem Präfix des Tabellennamens benennen, so dass der Spaltenname in der gesamten Datenbank gleich ist. Ich sehe diesen Punkt, aber Sie können einen Primärschlüssel nicht mehr visuell von einem Fremdschlüssel unterscheiden.

Außerdem denke ich, dass es überflüssig ist, den Tabellennamen im Spaltennamen zu haben, denn wenn Sie die Tabelle als eine Entität und eine Spalte als eine Eigenschaft oder ein Attribut dieser Entität betrachten, denken Sie an sie als das ID-Attribut der Employee, nicht der EmployeeID Attribut eines Mitarbeiters. Ich frage meinen Kollegen nicht, was sein PersonAge oder PersonGender ist. Ich frage ihn, wie alt er ist.

Also, wie ich schon sagte, es ist eine tobende Debatte, und wir gehen immer weiter und weiter. Ich interessiere mich für neue Perspektiven.


75
2017-09-02 19:13


Ursprung


Antworten:


Es ist nicht wirklich wichtig. Ich bin nie auf ein System gestoßen, bei dem es einen echten Unterschied zwischen Wahl 1 und Wahl 2 gibt.

Jeff Atwood hatte vor einiger Zeit einen großartigen Artikel zu diesem Thema. Im Grunde debattieren und streiten die Menschen am heftigsten über diese Themen, an denen sie sich nicht als falsch erweisen können. Oder aus einem anderen Blickwinkel jene Themen, die nur durch Filibuster-artige ausdauerbasierte Argumente gewonnen werden können.

Wählen Sie eine aus und sagen Sie ihnen, dass sie sich auf Probleme konzentrieren sollten, die sich auf Ihren Code auswirken.

EDIT: Wenn Sie Spaß haben möchten, haben Sie ausführlich angeben, warum ihre Methode für rekursive Tabellenreferenzen überlegen ist.


43
2017-09-02 19:18



Wenn die beiden Spalten in beiden Tabellen den gleichen Namen haben (Konvention # 2), können Sie die Syntax USING in SQL verwenden, um ein wenig Tippfehler und ein gewisses Rauschen vorzubeugen:

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

Ein weiteres Argument für die Konvention Nr. 2 ist, dass es so ist das relationale Modell wurde entworfen.

Die Bedeutung jeder Spalte ist   teilweise vermittelt durch Kennzeichnung mit   der Name der entsprechenden Domain


66
2017-09-02 19:52



Ich denke, es hängt davon ab, wie Sie Ihre Bewerbung zusammenstellen. Wenn Sie ORM verwenden oder Ihre Tabellen zur Darstellung von Objekten entwerfen, ist Option 1 möglicherweise für Sie geeignet.

Ich mag es, die Datenbank als eigene Ebene zu codieren. Ich kontrolliere alles und die App ruft nur gespeicherte Prozeduren auf. Es ist schön, Ergebnismengen mit vollständigen Spaltennamen zu haben, besonders wenn viele Tabellen verbunden sind und viele Spalten zurückgegeben werden. Mit dieser Art von Anwendung mag ich Option 2. Ich mag wirklich, dass Spaltennamen bei Joins übereinstimmen. Ich habe an alten Systemen gearbeitet, wo sie nicht zusammenpassen und es war ein Albtraum,


11
2017-09-02 19:35



Keine Konvention funktioniert in allen Fällen, also warum überhaupt eine? Nutze den gesunden Menschenverstand ...

Wenn zum Beispiel für eine selbstreferenzierende Tabelle mehr als eine FK-Spalte die PK der gleichen Tabelle selbst referenziert, müssen Sie beide "Standards" verletzen, da die beiden FK-Spalten nicht gleich benannt werden können ... z , EmployeeTable mit EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, ...


3
2017-09-02 19:33



Ich stimme zu, dass es wenig zu wählen gibt. Für mich ist der "Standard" -Teil viel wichtiger als Standard.

Wenn Leute anfangen, ihr eigenes Ding zu machen, sollten sie von ihren Nethern aufgereiht werden. MEINER BESCHEIDENEN MEINUNG NACH :)


3
2017-09-02 19:55



Wenn Sie Anwendungscode und nicht nur Datenbankabfragen betrachten, scheinen mir einige Dinge klar zu sein:

  1. Tabellendefinitionen werden normalerweise direkt einer Klasse zugeordnet, die ein Objekt beschreibt, daher sollten sie einzeln sein. Um eine Sammlung eines Objekts zu beschreiben, füge ich normalerweise "Array" oder "Liste" oder "Sammlung" an den singulären Namen an, da es deutlicher als die Verwendung von Plural nicht nur anzeigt, dass es sich um eine Sammlung handelt, sondern um welche Art von Sammlung es ist. In dieser Ansicht sehe ich einen Tabellennamen als nicht den Namen der Sammlung, sondern den Namen des Objekttyps, von dem es eine Sammlung ist. Ein DBA, der keinen Anwendungscode schreibt, könnte diesen Punkt übersehen.

  2. Die Daten, mit denen ich mich beschäftige, verwenden oft "ID" für Nicht-Schlüsselidentifikationszwecke. Um Verwechslungen zwischen Schlüssel-IDs und Nicht-Schlüssel-IDs zu vermeiden, verwenden wir für den Primärschlüsselnamen "Schlüssel" (so ist es, oder?), Dem der Tabellenname oder eine Abkürzung vorangestellt ist der Tabellenname Dieses Präfix (und ich reserviere das nur für den Primärschlüssel) macht den Schlüsselnamen einzigartig, was besonders wichtig ist, weil wir Variablennamen verwenden, die den Datenbankspaltennamen entsprechen, und die meisten Klassen haben einen Elternteil, der durch den Namen von identifiziert wird der übergeordnete Schlüssel Dies ist auch erforderlich, um sicherzustellen, dass es sich nicht um ein reserviertes Schlüsselwort handelt, welches "Schlüssel" allein ist. Um das Beibehalten von Schlüsselvariablennamen zu erleichtern und um Programme bereitzustellen, die natürliche Joins verwenden, haben Fremdschlüssel denselben Namen wie in der Tabelle, in der sie der Primärschlüssel sind. Ich habe mehr als einmal Programme kennengelernt, die auf diese Weise mit natürlichen Joins viel besser arbeiten. Zu diesem letzten Punkt gebe ich ein Problem mit selbstverweisenden Tabellen zu, die ich benutzt habe. In diesem Fall würde ich eine Ausnahme für die Fremdschlüsselbenennungsregel machen. Zum Beispiel würde ich ManagerKey als Fremdschlüssel in der Employee-Tabelle verwenden, um auf einen anderen Datensatz in dieser Tabelle zu verweisen.


2
2018-04-30 19:23



Ich mag Convention # 2 - in der Erforschung dieses Themas, und das Finden dieser Frage vor der Veröffentlichung meiner eigenen, stieß ich auf das Problem, wo:

Ich wähle * aus einer Tabelle mit einer großen Anzahl von Spalten und verbinde sie mit einer zweiten Tabelle, die ebenfalls eine große Anzahl von Spalten aufweist. Beide Tabellen haben eine "id" -Spalte als Primärschlüssel, und das bedeutet, dass ich jede Spalte (soweit ich weiß) spezifisch auswählen muss, um diese beiden Werte im Ergebnis eindeutig zu machen, d. H .:

SELECT table1.id AS parent_id, table2.id AS child_id

Obwohl die Verwendung von Konvention 2 bedeutet, dass ich noch einige Spalten im Ergebnis mit dem gleichen Namen haben werde, kann ich jetzt spezifizieren welche Ich brauche (Eltern oder Kind) und, wie Steven Huwig vorgeschlagen hat, die USING Aussage vereinfacht die Dinge weiter.


2
2018-04-30 19:33



Ich habe es immer benutzt Benutzeridentifikation als PK auf einem Tisch und Benutzeridentifikation auf einem anderen Tisch als FK. Ich denke ernsthaft über die Verwendung nach Benutzer-IDPK und userIdFK als Namen, um sich voneinander zu unterscheiden. Es wird mir helfen, PK und FK schnell zu erkennen, wenn ich mir die Tabellen anschaue, und es scheint, als würde es Code aufräumen, wenn man PHP / SQL benutzt, um auf Daten zuzugreifen, die es leichter verständlich machen. Vor allem, wenn sich jemand anders meinen Code ansieht.


2
2017-12-15 11:27



Die Konvention, die wir verwenden, wo ich arbeite, ist ziemlich nah an A, mit der Ausnahme, dass wir Tabellen im Plural (dh "Angestellte") benennen und Unterstriche zwischen dem Tabellen- und Spaltennamen verwenden. Der Vorteil besteht darin, dass es sich auf eine Spalte bezieht, entweder "employees_id" oder "employees.id", je nachdem, wie Sie darauf zugreifen möchten. Wenn Sie angeben müssen, aus welcher Tabelle die Spalte stammt, ist "employees.employees_id" definitiv redundant.


1
2017-09-02 19:21



Ich verwende die Konvention # 2. Ich arbeite jetzt mit einem Legacy-Datenmodell, in dem ich nicht weiß, was in einer bestimmten Tabelle steht. Wo ist der Schaden, wenn man ausführlich ist?


1
2017-09-02 19:28