Warum wird das Präfixieren von Spaltennamen als schlechte Praxis angesehen?

Laut einem populären SO-Post wird das Präfixieren von Tabellennamen als schlechte Praxis angesehen. In meiner Firma wird jeder Spalte ein Tabellenname vorangestellt. Das ist für mich schwer zu lesen. Ich bin mir nicht sicher, warum, aber diese Benennung ist eigentlich der Firmenstandard. Ich kann die Namenskonvention nicht ausstehen, aber ich habe keine Dokumentation, um meine Argumentation zu stützen.

Ich weiß nur, dass das Lesen von AdventureWorks viel einfacher ist. In dieser Unternehmensdatenbank sehen Sie eine Tabelle, Person und möglicherweise einen Spaltennamen:

Person_First_Name
oder vielleicht sogar
Person_Person_First_Name (frag mich nicht, warum du Person 2x siehst)

Warum wird es als schlechte Praxis angesehen, Spaltennamen vorab festzulegen? Werden Unterstriche auch in SQL als böse angesehen?

Unterstriche sind nicht schlecht, nur schwieriger zu tippen. Was schlecht ist, ist die Änderung der Standards in der Mitte des Datenflusses, ohne alle vorhandenen Objekte zu reparieren. Jetzt haben Sie personId, Person_id usw. und können sich nicht erinnern, welche Tabelle die Unterstriche verwendet oder nicht. Eine einheitliche Benennung (auch wenn Sie die Namen persönlich nicht mögen) erleichtert das Codieren.

Ich persönlich bin der Meinung, dass der Tabellenname in einer Spalte nur in der ID-Spalte verwendet werden muss (die Verwendung von nur ID ist ein Antimuster im Datenbankdesign, wie Ihnen jeder mitteilen kann, der umfangreiche Berichtsabfragen durchgeführt hat. Es macht so viel Spaß, ihn umzubenennen 12 Spalten in Ihrer Abfrage, wenn Sie einen Bericht schreiben.) Dadurch ist es auch einfacher, die FKs in anderen Tabellen, die denselben Namen haben, sofort zu erkennen.

In einer ausgereiften Datenbank ist es jedoch mehr Arbeit, als es sich lohnt, einen vorhandenen Standard zu ändern. Akzeptieren Sie einfach, dass dies der Standard ist, und fahren Sie fort. Es gibt weitaus kritischere Dinge, die zuerst behoben werden müssen.

Ein Argument für das Präfix des Spaltennamens wäre das Verhindern von Namenskollisionen beim Verknüpfen mehrerer Tabellen UND wenn der Ersteller der Abfrage keine Aliase verwendet.

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

Beide Abfragen hätten zwei "name" -Spalten ( name_1, name_2 ), ohne zu "sagen", zu welcher Entität sie gehört. Und Sie können nie sicher sein, welche Spaltennamen generiert wurden (wird es name_2 oder name_3 oder ... sein). Wenn Sie das Präfix für den Tabellennamen verwenden , lauten die Spaltennamen " person_name" und " company_name", sodass Sie wissen, zu welcher Entität sie gehört. Außerdem wissen Sie, dass die Spaltennamen konstant bleiben (wenn Sie sie in Java beispielsweise mithilfe von JDBC abrufen ).

Beide Argumente können ignoriert werden, wenn Sie Aliasing verwenden, aber ich denke, die meisten Kodierungskonventionen, die in Unternehmen durchgesetzt werden, sind die Folge vieler (Junior-) Programmierer, die sich nicht an bewährte Praktiken halten. In diesem Fall kann beispielsweise die Verwendung des Platzhalters in einer SELECT-Anweisung Probleme verursachen, wenn der Name nicht vorangestellt wird.

Der Unterstrich in Tabellen- und Spaltennamen wird häufig verwendet, da nur Kleinbuchstaben in Namen plus Unterstrich als Trennzeichen verwendet werden. Wenn Sie nur Kleinbuchstaben verwenden, können Sie Bezeichner von SQL-Schlüsselwörtern unterscheiden (die ich in Großbuchstaben schreibe):

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'

Das Hinzufügen solcher Präfixe zu Spaltennamen erschwert die Entwicklung einer Tabelle. Als Beispiel: Wenn Sie irgendwann feststellen, dass Sie den Tabellennamen ändern möchten / müssen, müssen Sie Ihre gesamte Tabellenstruktur ändern (dh nicht nur den Namen der Tabelle, sondern den Namen aller Spalten). Dies würde auch die Aktualisierung der Tabellenindizes und des Codes der Clients, die diese abfragen, erschweren.

Es gibt Ausnahmen, wenn sie für gebräuchliche Spaltennamen (normalerweise nur ID, manchmal Name) mit Bedacht verwendet werden (wie in der Antwort von Patrick Karcher auf Ihren Link angegeben), die zu oft nicht eindeutig sind .

Eine weitere bewährte Methode besteht darin, Spalten und Objekte in Ihren Abfragen immer zu qualifizieren. So werden Spaltenpräfixe umstritten und überladen Ihren Code.

Vergleichen Sie diese: Was ist am Auge am einfachsten?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person

Im Allgemeinen scheint es wirklich keine allgegenwärtigen Standards zu geben. Die Frage, mit der Sie verknüpft haben, hat mehrere Antworten mit sehr unterschiedlichen Konventionen. Natürlich wird jeder seine eigenen Standards verteidigen, und es ist viel wichtiger, in einem Projekt konsequente Konventionen einzuhalten.

Das heißt, das Präfixieren von Spaltennamen scheint übertrieben zu sein. Sie wissen bereits, mit welcher Tabelle Sie arbeiten, und eine Situation mit zwei Spalten aus verschiedenen Tabellen mit demselben Namen kann mithilfe von Tabellen- oder Spaltenaliasnamen leicht gelöst werden.

In TSQL können Sie auf Felder in der Form TableName.FieldName verweisen, wenn Sie Mehrdeutigkeiten vermeiden möchten, damit das Hinzufügen von Tabellennamen zu Feldnamen die Lesbarkeit beeinträchtigt und es zu TableName.TableName_FieldName oder einem ähnlichen Element macht. Ich denke, Unterstriche zu verwenden oder nicht, ist eher eine persönliche Entscheidung. Ich bevorzuge CamelCase und benutze _, wenn ich ein Suffix oder ähnliches hinzufügen möchte, zB TableName_Temp, aber das bin nur ich.

Ich habe einmal an einem System gearbeitet, in dem wir beschlossen haben, Funktionscodes zu verwenden, um die Spalten voranzustellen. In den PK-Feldern wurde der "vollständige Tabellenname" als Präfix verwendet, und in allen anderen Spalten wurden durchgehend 2 bis 4 Zeichen als Präfix verwendet. Jede Spalte verwendete auch eine Datendomäne als Suffix. Wenn es konsequent gemacht wird, kann es sehr schön und sauber sein. Es ist Unsinn, dass ein Namensstandard des einen oder anderen Typs eine schlampige Codierung impliziert. Das Vorhandensein eines einheitlichen Standards ist wichtig. Ich habe eine Reihe von Datenbanken gesehen, die inkonsistent sind, weil es keinen klaren Standard gibt, und dass mir mehr als alles andere darauf hindeuten würde, dass es Probleme in den Datenstrukturen geben könnte. Wenn der Designer einer Datenbank Objekte und ihre untergeordneten Objekte nicht einheitlich benennen kann,

Das Präfixieren ist eine schlechte Praxis, da es das Problem verursacht, das verhindert werden soll. Wie Sie sagten, ist es sehr schwer, vorangestellte Spalten zu lesen. Wenn in einer Abfrage, in der Sie zwei Tabellen verknüpfen, doppelte Spaltennamen auftreten, können Sie diese auflösen oder es handelt sich um eine Ansicht, eine gespeicherte Prozedur oder eine benutzerdefinierte Tabellenfunktion, die dies für Sie erledigt, wenn Sie ständig bestimmte Tabellen verknüpfen.

Soweit die Verwendung in einem Tabellennamen unterstrichen ist, ist dies ein religiöses Argument. Am Ende wird die Sichtbarkeit erhöht und es wird einfacher. Ich würde im Allgemeinen niemals Leerzeichen oder Tabellen in einer Spalte oder einem Tabellennamen haben. Möglicherweise mache ich jedoch eine Ausnahme für Tabellen oder Ansichten, die nur von einem Berichtspaket verwendet oder in eine CSV-Datei exportiert wurden.

Bei vielen Datenbanken ist die Anzahl der Zeichen in einem Spaltennamen streng begrenzt (z. B. Oracle).

Wenn Sie mit einer Datenbank arbeiten, die lange Spaltennamen zulässt, diese Struktur jedoch später auf ein anderes Datenbanksystem migrieren möchten, erhöhen die Präfixe die Wahrscheinlichkeit, dass Ihre Spaltennamen ungültig werden.

Obwohl Sie jetzt mit SQL Server arbeiten, kann niemand die Zukunft vorhersagen, und es ist möglich, dass Ihre Software in Zukunft an mehreren Datenbanken arbeiten muss.

Erwägen Sie, ein Datenwörterbuch (oder eine "Registrierung") zu schreiben. Damit meine ich ein Dokument, das alle Datenelemente in Ihrem Modell enthält: Name, Beschreibung usw. Es sollte unabhängig von der Implementierung des Modells sein, z. B. keine Tabellennamen erwähnen. Wie würden Sie Namen wie "ID", "Typ" und "Code" unterscheiden?

Ein Ansatz ist es, die Richtlinien der internationalen Norm ISO / IEC 11179 zu befolgen - schließlich warum das Rad neu erfinden? Die Grundstruktur ist:

[Object] [Qualifier] Property RepresentationTerm

mit Trennzeichen zwischen den Elementen: SQL spielt nicht gut mit Leerzeichen in Spaltennamen und der Unterstrich funktioniert gut visuell.

Ich habe das Gefühl, dass jemand in Ihrer Organisation versucht hat, diese Richtlinien zu befolgen, als er mit Elementnamen wie Person_Person_First_Name.

Das Beispiel, das ich gerne zeige, ist das Datenwörterbuch des UK Nation Health Service (NHS) .

Daher finde ich die Namenskonvention, mit der man arbeiten muss, nicht schlecht.

Auf Implementierung zB in SQL, wie einige Volks das Objekt, Qualifier und Objektunterelemente , wenn der Tabellenname Kontext zB wegzulassen liefert person_first_namewird first_namein der PersonTabelle usw. Um jedoch die Daumenregel , dass ein Datenelement sollte seinen Namen nicht einfach ändern Aufgrund seiner Position im physischen Modell scheint es ein gutes zu sein. Jeder, der der Meinung ist, dass es keine gute Idee ist, diese Regel zu befolgen, sollte die Aufgabe haben, alle von ihm verwendeten Namensvarianten zu dokumentieren :)

Eine schöne Zusammenfassung von ISO 11179 finden Sie im Buch Joe Celkos Programmierstil , einschließlich der Beweise für den Vorzug von Unterstrichen als Trennzeichen in Spaltennamen.

Einige finden es im Code einfacher zu wissen, aus welcher Tabelle die Daten stammen. Wenn Sie jedoch über ein objektorientiertes System sprechen, sollten Sie den Kontext des Namens verwenden, um zu wissen, woher er stammt, in diesem Fall den Tabellennamen.

Persönlich ist das Präfixieren des Tabellennamens ein Hinweis darauf, dass die Entwickler nicht sehr erfahren sind. Wenn Sie genauer hinschauen, werden Sie viele andere schlechte Codierungskonventionen finden, und wenn ich vermuten müsste, dass die App zu viele Tabellen hat, fehlerhaft ist usw.