Namenskonvention für Primärschlüssel / Fremdschlüssel [geschlossen]

In unserer Entwicklergruppe führen wir eine heftige Debatte über die Namenskonvention für Primär- und Fremdschlüssel. Grundsätzlich gibt es in unserer Gruppe zwei Denkschulen:

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 (daher bevorzuge ich Option 1 oben). Konzeptionell stimmt es mit vielen empfohlenen Vorgehensweisen in anderen Sprachen überein, in denen Sie den Namen des Objekts nicht in seinen Eigenschaftsnamen verwenden. Ich denke, dass die Benennung des Fremdschlüssels EmployeeID(oder Employee_IDbesser) dem Leser sagt, dass es sich um die IDSpalte der EmployeeTabelle handelt.

Einige andere bevorzugen Option 2, bei der Sie den Primärschlüssel mit dem Präfix "Tabellenname" benennen, damit der Spaltenname in der gesamten Datenbank identisch ist. Ich sehe diesen Punkt, aber Sie können jetzt einen Primärschlüssel nicht visuell von einem Fremdschlüssel unterscheiden.

Ich denke auch, dass es überflüssig ist, den Tabellennamen im Spaltennamen zu haben, denn wenn Sie die Tabelle als Entität und eine Spalte als Eigenschaft oder Attribut dieser Entität betrachten, betrachten Sie sie als ID-Attribut der Employee, nicht das EmployeeIDAttribut eines Mitarbeiters. Ich gehe nicht und frage meinen Kollegen, was sein PersonAgeoder PersonGenderist. Ich frage ihn, wie alt er ist.

Wie ich schon sagte, es ist eine heftige Debatte und wir gehen weiter und weiter und weiter darüber. Ich bin daran interessiert, neue Perspektiven zu bekommen.

Es ist nicht wirklich wichtig. Ich bin noch 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. Grundsätzlich diskutieren und argumentieren die Menschen am heftigsten über die Themen, bei denen sie sich nicht als falsch erweisen können. Oder aus einem anderen Blickwinkel, jene Themen, die nur durch ausdauernde Argumente im Filibuster-Stil gewonnen werden können.

Wählen Sie eine aus und fordern Sie sie auf, sich auf Probleme zu konzentrieren, die sich tatsächlich auf Ihren Code auswirken.

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

Wenn die beiden Spalten in beiden Tabellen denselben Namen haben (Konvention Nr. 2), können Sie die USING-Syntax in SQL verwenden, um Tippfehler und Boilerplate-Rauschen zu vermeiden:

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

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

Die Bedeutung jeder Spalte wird teilweise durch Kennzeichnung mit dem Namen der entsprechenden Domäne vermittelt.

Ich denke, es hängt davon ab, wie Ihre Bewerbung zusammengestellt ist. 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, insbesondere wenn viele Tabellen verknüpft und viele Spalten zurückgegeben werden. Bei diesem Anwendungstyp gefällt mir Option 2. Ich mag es wirklich, wenn Spaltennamen bei Verknüpfungen übereinstimmen. Ich habe an alten Systemen gearbeitet, bei denen sie nicht übereinstimmten, und es war ein Albtraum.

Keine der beiden Konventionen funktioniert in allen Fällen. Warum also überhaupt eine? Verwenden Sie den gesunden Menschenverstand ...

Wenn es beispielsweise für eine selbstreferenzierende Tabelle mehr als eine FK-Spalte gibt, die auf die PK derselben Tabelle selbst verweist, 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, ...

Ich stimme zu, dass es wenig zu wählen gibt. Für mich ist der "Standard" -Teil eine viel wichtigere Sache bei beiden Standards.

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

Haben Sie Folgendes berücksichtigt?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

Die Konvention, die wir bei meiner Arbeit verwenden, liegt ziemlich nahe bei A, mit der Ausnahme, dass wir Tabellen im Plural benennen (dh "Mitarbeiter") und Unterstriche zwischen dem Tabellen- und Spaltennamen verwenden. Der Vorteil davon ist, dass für den Verweis auf eine Spalte entweder "employee _ id" oder "employee.id" angegeben wird, je nachdem, wie Sie darauf zugreifen möchten. Wenn Sie angeben müssen, aus welcher Tabelle die Spalte stammt, ist "employee.employees _ id" definitiv redundant.

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

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

2. Die Daten, mit denen ich mich beschäftige, verwenden häufig "ID" zur Identifizierung ohne Schlüssel. Um Verwechslungen zwischen Schlüssel- "IDs" und Nicht-Schlüssel- "IDs" zu vermeiden, verwenden wir für den Primärschlüsselnamen "Schlüssel" (das ist es, nicht wahr?), Dem der Tabellenname oder eine Abkürzung von vorangestellt ist der Tabellenname. Dieses Präfix (und ich reserviere dies nur für den Primärschlüssel) macht den Schlüsselnamen eindeutig, was besonders wichtig ist, da wir Variablennamen verwenden, die mit den Namen der Datenbankspalten identisch sind, und die meisten Klassen ein übergeordnetes Element haben, das 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, sondern nur um "Schlüssel". Um die Konsistenz der wichtigsten Variablennamen zu erleichtern und Programme bereitzustellen, die natürliche Verknüpfungen ausführen, Fremdschlüssel haben denselben Namen wie in der Tabelle, in der sie der Primärschlüssel sind. Ich bin mehr als einmal auf Programme gestoßen, die auf diese Weise mit natürlichen Verknüpfungen viel besser funktionieren. In diesem letzten Punkt gebe ich ein Problem mit selbstreferenzierenden Tabellen zu, die ich verwendet habe. In diesem Fall würde ich eine Ausnahme von der Fremdschlüssel-Namensregel 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.

Ich mag Konvention Nr. 2 - als ich dieses Thema recherchierte und diese Frage fand, bevor ich meine eigene veröffentlichte, stieß ich auf das Problem, bei dem:

Ich wähle * aus einer Tabelle mit einer großen Anzahl von Spalten aus und verbinde sie mit einer zweiten Tabelle, die ebenfalls eine große Anzahl von Spalten enthält. 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, dh:

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

Obwohl die Verwendung von Konvention Nr. 2 bedeutet, dass das Ergebnis immer noch einige Spalten mit demselben Namen enthält, kann ich jetzt angeben, welche ID ich benötige (Eltern oder Kind), und wie Steven Huwig vorgeschlagen hat, USINGvereinfacht die Anweisung die Dinge weiter.

Ich habe immer userId als PK für eine Tabelle und userId für eine andere Tabelle als FK verwendet. Ich denke ernsthaft darüber nach, userIdPK und userIdFK als Namen zu verwenden, um sie voneinander zu unterscheiden. Es wird mir helfen, PK und FK beim Betrachten der Tabellen schnell zu identifizieren, und es scheint, als würde es den Code aufklären, wenn PHP / SQL für den Zugriff auf Daten verwendet wird, um das Verständnis zu erleichtern. Besonders wenn jemand anderes meinen Code ansieht.

Ich benutze Konvention # 2. Ich arbeite jetzt mit einem alten Datenmodell, bei dem ich nicht weiß, wofür in einer bestimmten Tabelle steht. Wo ist der Schaden, wenn man wortreich ist?

Wie wäre es mit der Benennung des Fremdschlüssels?

role_id

Dabei ist Rolle die Rolle, die die referenzierte Entität relativ zur vorliegenden Tabelle hat. Dies löst das Problem der rekursiven Referenz und mehrerer fks auf dieselbe Tabelle.

In vielen Fällen ist der Name der referenzierten Tabelle identisch. In diesem Fall wird es identisch mit einem Ihrer Vorschläge.

Auf jeden Fall ist es eine schlechte Idee, lange Argumente zu haben

"Wo in" Mitarbeiter INNER JOIN order ON order.employee_id = employee.id "besteht Bedarf an zusätzlicher Qualifikation?".

Es ist keine zusätzliche Qualifikation erforderlich, da die Qualifikation, von der ich gesprochen habe, bereits vorhanden ist.

"Der Grund, warum ein Geschäftsbenutzer auf die Auftrags-ID oder die Mitarbeiter-ID verweist, besteht darin, den Kontext anzugeben. Auf Datenbankebene haben Sie jedoch bereits einen Kontext, weil Sie sich auf die Tabelle beziehen."

Beten Sie, sagen Sie mir, wenn die Spalte den Namen "ID" trägt, wie wird dann das "Verweisen auf die Tabelle" genau durchgeführt, es sei denn, Sie qualifizieren diesen Verweis auf die ID-Spalte genau so, wie ich es erwähnt habe?