Benennung von ID-Spalten in Datenbanktabellen

Ich habe mich gefragt, welche Meinungen die Leute zur Benennung von ID-Spalten in Datenbanktabellen haben.

Wenn ich eine Tabelle namens Rechnungen mit einem Primärschlüssel einer Identitätsspalte habe, würde ich diese Spalte InvoiceID aufrufen, damit ich nicht mit anderen Tabellen in Konflikt gerate und es offensichtlich ist, was es ist.

Wo ich aktuell arbeite, haben sie alle ID-Spalten ID aufgerufen.

Also würden sie Folgendes tun:

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

Jetzt sehe ich hier einige Probleme:
1. Sie müssten die Spalten auf der Auswahl
aliasen. 2. ID = InvoiceID passt nicht in mein Gehirn.
3. Wenn Sie die Tabellen nicht aliasisiert und auf InvoiceID verwiesen haben, ist es offensichtlich, welche Tabelle es läuft?

Was denken andere Leute über das Thema?

ID ist ein SQL Antipattern. Siehe http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+a

Wenn Sie viele Tabellen mit der ID als ID haben, erschweren Sie die Berichterstellung erheblich. Es verschleiert die Bedeutung und erschwert das Lesen komplexer Abfragen. Außerdem müssen Sie Aliase verwenden, um den Bericht selbst zu unterscheiden.

Wenn jemand dumm genug ist, einen natürlichen Join in einer Datenbank zu verwenden, in der er verfügbar ist, werden Sie sich den falschen Datensätzen anschließen.

Wenn Sie die USING-Syntax verwenden möchten, die einige DBs zulassen, können Sie dies nicht, wenn Sie ID verwenden.

Wenn Sie ID verwenden, kann dies leicht zu einem fehlerhaften Join führen, wenn Sie zufällig die Join-Syntax kopieren (sagen Sie mir nicht, dass dies niemals jemand tut!) Und vergessen, den Alias ​​in der Join-Bedingung zu ändern.

Also hast du jetzt

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

als du meintest

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

Wenn Sie tablenameID als ID-Feld verwenden, ist diese Art von versehentlichem Fehler weitaus weniger wahrscheinlich und viel einfacher zu finden.

Ich habe immer ID gegenüber TableName + ID für die ID-Spalte und dann TableName + ID für einen Fremdschlüssel vorgezogen. Auf diese Weise haben alle Tabellen den gleichen Namen für das ID-Feld und es gibt keine redundante Beschreibung. Dies erscheint mir einfacher, da alle Tabellen denselben Primärschlüsselfeldnamen haben.

Soweit Tabellen verknüpft werden und nicht bekannt ist, welches ID-Feld zu welcher Tabelle gehört, sollte meiner Meinung nach die Abfrage geschrieben werden, um diese Situation zu bewältigen. Wo ich arbeite, stellen wir den Feldern, die wir in einer Anweisung verwenden, immer den Alias ​​table / table voran.

In letzter Zeit gab es in meiner Gesellschaft einen Nerd-Kampf um genau diese Sache. Das Aufkommen von LINQ hat das redundante Tabellenname + ID- Muster in meinen Augen noch offensichtlicher albern gemacht. Ich denke, die meisten vernünftigen Leute werden sagen, wenn Sie Ihr SQL von Hand so schreiben, dass Sie Tabellennamen angeben müssen, um FKs zu unterscheiden, bedeutet dies nicht nur eine Einsparung bei der Eingabe, sondern es erhöht auch die Klarheit, wenn Sie Ihr SQL nur verwenden Anhand der ID können Sie deutlich erkennen, welche PK und welche FK ist .

Z.B

VON Mitarbeitern e LEFT JOIN Kunden c ON e.ID = c.EmployeeID

sagt mir nicht nur, dass die beiden verbunden sind, sondern welche die PK und welche die FK ist . Während man im alten Stil gezwungen ist, entweder zu schauen oder zu hoffen, dass sie gut benannt wurden.

Wir benutzen InvoiceIDnicht ID. Dadurch werden Abfragen besser lesbar - wenn Sie IDalleine sehen, kann dies alles bedeuten, insbesondere wenn Sie die Tabelle mit einem Alias ​​versehen i.

Ich stimme Keven und einigen anderen Personen hier zu, dass die PK für eine Tabelle einfach ID sein sollte und Fremdschlüssel die OtherTable + Id auflisten sollten.

Ich möchte jedoch einen Grund hinzufügen, der dieser Argumentation kürzlich mehr Gewicht verlieh.

In meiner aktuellen Position verwenden wir das Entity Framework mithilfe der POCO-Generierung. Unter Verwendung der Standard-Namenskonvention von Id ermöglicht die PK die Vererbung einer Basis-Poco-Klasse mit Validierung und dergleichen für Tabellen, die eine Reihe gemeinsamer Spaltennamen verwenden. Die Verwendung des Tabellennamens + der ID als PK für jede dieser Tabellen zerstört die Möglichkeit, eine Basisklasse für diese zu verwenden.

Nur ein paar Denkanstöße.

Meine Präferenz ist auch ID für Primärschlüssel und TableNameID für Fremdschlüssel. Ich möchte auch eine Spalte "Name" in den meisten Tabellen haben, in denen ich die vom Benutzer lesbare Kennung (dh Name :-)) des Eintrags habe. Diese Struktur bietet große Flexibilität in der Anwendung selbst. Ich kann Tabellen in Masse auf die gleiche Weise behandeln. Das ist eine sehr mächtige Sache. Normalerweise wird eine OO-Software auf der Datenbank erstellt, aber das OO-Toolset kann nicht angewendet werden, da die Datenbank selbst dies nicht zulässt. Die Spalten-ID und den Namen zu haben ist immer noch nicht sehr gut, aber es ist ein Schritt.

Wählen Sie
i.ID, il.ID aus Rechnungen aus. I Left Join InvoiceLines il on i.ID = il.InvoiceID

Warum kann ich das nicht tun?

Select  
    Invoices.ID 
,   InvoiceLines.ID 
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

Meiner Meinung nach ist dies sehr gut lesbar und einfach. Das Benennen von Variablen als i und il ist im Allgemeinen eine schlechte Wahl.

Es ist nicht wirklich wichtig, dass Sie wahrscheinlich in allen Namenskonventionen auf ähnliche Probleme stoßen.

Es ist jedoch wichtig, konsistent zu sein, damit Sie nicht jedes Mal, wenn Sie eine Abfrage schreiben, die Tabellendefinitionen überprüfen müssen.

Ich habe gerade angefangen, an einem Ort zu arbeiten, der nur "ID" verwendet (in den Kerntabellen, auf die TableNameID in Fremdschlüsseln verweist), und habe bereits ZWEI Produktionsprobleme gefunden, die direkt dadurch verursacht wurden.

In einem Fall verwendete die Abfrage "... where ID in (SELECT ID FROM OtherTable ..." anstelle von "... where ID in (SELECT TransID FROM OtherTable ...").

Kann jemand ehrlich sagen, dass es nicht viel einfacher gewesen wäre, zu erkennen, wenn vollständige, konsistente Namen verwendet worden wären, bei denen die falsche Aussage "... wo TransID in (SELECT OtherTableID from OtherTable ...") lautete? Ich glaube nicht so.

Das andere Problem tritt beim Refactoring von Code auf. Wenn Sie eine temporäre Tabelle verwenden, während zuvor die Abfrage von einer Kerntabelle entfernt wurde, lautet der alte Code "... dbo.MyFunction (t.ID) ...". Wenn dies nicht geändert wird, bezieht sich "t" jetzt auf a temporäre Tabelle anstelle der Kerntabelle erhalten Sie nicht einmal einen Fehler - nur fehlerhafte Ergebnisse.

Wenn das Erzeugen unnötiger Fehler ein Ziel ist (vielleicht haben einige Leute nicht genug Arbeit?), Dann ist diese Art der Namenskonvention großartig. Ansonsten ist eine einheitliche Benennung der richtige Weg.

Der Einfachheit halber benennen die meisten Leute die Spalte in der Tabellen-ID. Wenn es eine Fremdschlüsselreferenz in einer anderen Tabelle gibt, wird sie bei Verknüpfungen explizit InvoiceID genannt (um Ihr Beispiel zu verwenden). Sie führen die Tabelle trotzdem als Alias ​​aus, sodass die explizite inv.ID immer noch einfacher als inv.InvoiceID ist

Ich persönlich bevorzuge (wie oben angegeben) die Table.ID für die PK und die TableID für die FK . Auch (bitte erschieß mich nicht) Microsoft Access empfiehlt dies.

JEDOCH weiß ich AUCH, dass einige Generierungswerkzeuge die TableID für PK bevorzugen, da sie dazu neigen, alle Spaltennamen zu verknüpfen, die 'ID' im Wort enthalten, EINSCHLIESSLICH ID !!!

Sogar der Abfrage-Designer tut dies auf Microsoft SQL Server (und für jede von Ihnen erstellte Abfrage werden alle unnötigen neu erstellten Beziehungen für alle Tabellen in der Spalten-ID entfernt).

So sehr meine interne OCD es hasst, ich rolle mit der TableID- Konvention. Erinnern wir uns daran , dass es eine Daten genannt BASE , da es die Basis für hoffentlich viele viele viele Anwendungen sein zu kommen. Und alle Technologien sollten von einem gut normalisierten Schema mit klarer Beschreibung profitieren.

Es versteht sich von selbst, dass ich meine Linie ziehe, wenn Leute anfangen, TableName, TableDescription und so weiter zu verwenden. Meiner Meinung nach sollten Konventionen Folgendes tun:

• Tabellenname: Pluralisiert. Ex. Angestellte

• Tabellenalias: Vollständiger Tabellenname, singulär. Ex.

  SELECT Employee.*, eMail.Address
  FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well

[Aktualisieren]

Außerdem gibt es in diesem Thread einige gültige Beiträge zu doppelten Spalten aufgrund der "Art der Beziehung" oder Rolle. Wenn ein Geschäft beispielsweise eine EmployeeID hat, sagt mir das, dass ich in die Hocke gehe. Also mache ich manchmal so etwas wie Store.EmployeeID_Manager . Sicher, es ist etwas größer, aber zumindest werden die Leute nicht verrückt, wenn sie versuchen, die Tabellen-Manager-ID zu finden , oder was die Mitarbeiter- ID dort tut. Wenn die Abfrage WO ist, würde ich es vereinfachen als: SELECT EmployeeID_Manager als ManagerID FROM Store

Aus der Perspektive eines formalen Datenwörterbuchs würde ich das Datenelement benennen invoice_ID. Im Allgemeinen ist ein Datenelementname im Datenwörterbuch eindeutig und hat im Idealfall durchgehend denselben Namen, obwohl manchmal zusätzliche qualifizierende Begriffe basierend auf dem Kontext erforderlich sein können, z. B. könnte das genannte Datenelement employee_IDzweimal im Organigramm verwendet und daher als qualifiziert werden supervisor_employee_IDund subordinate_employee_IDjeweils.

Namenskonventionen sind natürlich subjektiv und eine Frage des Stils. Ich finde, dass ISO / IEC 11179-Richtlinien ein nützlicher Ausgangspunkt sind.

Für das DBMS sehe ich Tabellen als Sammlungen von Entiten (mit Ausnahme derjenigen, die immer nur eine Zeile enthalten, z. B. cofig-Tabelle, Konstantentabelle usw.), z. B. würde die Tabelle, in der my employee_IDder Schlüssel ist, benannt werden Personnel. Die TableNameIDKonvention funktioniert also nicht sofort für mich.

Ich habe den TableName.ID=PK TableNameID=FKStil gesehen, der bei großen Datenmodellen verwendet wird, und muss sagen, dass ich ihn etwas verwirrend finde: Ich bevorzuge es, dass der Name eines Bezeichners überall gleich ist, dh der Name ändert sich nicht basierend auf der Tabelle, in der er gerade angezeigt wird Der oben genannte Stil scheint in den Läden verwendet zu werden, die jeder Tabelle eine IDENTITYSpalte (automatische Inkrementierung) hinzufügen, während natürliche und zusammengesetzte Schlüssel in Fremdschlüsseln vermieden werden. Diese Shops verfügen in der Regel weder über formale Datenwörterbücher noch bauen sie aus Datenmodellen auf. Auch dies ist nur eine Frage des Stils und eine, die ich persönlich nicht abonniere. Letztendlich ist es also nichts für mich.

Trotzdem kann ich sehen, dass das Qualifikationsmerkmal manchmal aus dem Spaltennamen entfernt wird, wenn der Name der Tabelle einen Kontext dafür bereitstellt, z. B. kann das genannte Element employee_last_nameeinfach last_namein die PersonnelTabelle aufgenommen werden. Das Grundprinzip hier ist, dass die Domain "Nachnamen von Personen" ist und eher UNIONmit last_nameSpalten aus anderen Tabellen als mit einem Fremdschlüssel in einer anderen Tabelle verwendet wird, aber andererseits ... Ich könnte meine Meinung ändern, manchmal kann man nie sagen. Das ist die Sache: Datenmodellierung ist Teil Kunst, Teil Wissenschaft.

Ich denke, Sie können alles für die "ID" verwenden, solange Sie konsistent sind. Das Einfügen des Tabellennamens ist wichtig für. Ich würde vorschlagen, ein Modellierungswerkzeug wie Erwin zu verwenden, um die Namenskonventionen und -standards durchzusetzen. Wenn Sie also Abfragen schreiben, ist es leicht zu verstehen, welche Beziehungen zwischen Tabellen bestehen können.

Was ich mit der ersten Aussage meine, ist, dass Sie anstelle von ID etwas anderes wie 'recno' verwenden können. Dann hätte diese Tabelle eine PK von invoice_recno und so weiter.

Prost, Ben

Ich stimme für InvoiceID für die Tabellen-ID. Ich verwende dieselbe Namenskonvention auch, wenn sie als Fremdschlüssel verwendet wird, und verwende intelligente Aliasnamen in den Abfragen.

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

Sicher, es ist länger als einige andere Beispiele. Aber lächle. Dies ist für die Nachwelt und eines Tages wird ein armer Junior-Programmierer Ihr Meisterwerk ändern müssen. In diesem Beispiel gibt es keine Mehrdeutigkeit. Wenn der Abfrage zusätzliche Tabellen hinzugefügt werden, sind Sie für die Ausführlichkeit dankbar.

Für den Spaltennamen in der Datenbank würde ich "InvoiceID" verwenden.

Wenn ich die Felder über LINQ in eine unbenannte Struktur kopiere, kann ich sie dort "ID" nennen, wenn es die einzige ID in der Struktur ist.

Wenn die Spalte NICHT in einem Fremdschlüssel verwendet werden soll, sodass sie nur zur eindeutigen Identifizierung einer Zeile zum Bearbeiten oder Löschen von Bearbeitungen verwendet wird, werde ich sie "PK" nennen.

Wenn Sie jedem Schlüssel einen eindeutigen Namen geben, z. B. "invoices.invoice_id" anstelle von "invoices.id", können Sie die Operatoren "natural join" und "using" ohne Bedenken verwenden. Z.B

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

anstatt

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

SQL ist ausführlich genug, ohne es ausführlicher zu machen.

Um die Dinge für mich konsistent zu halten (wobei eine Tabelle einen einspaltigen Primärschlüssel als ID verwendet), benenne ich den Primärschlüssel der Tabelle Table_pk. Überall dort, wo ein Fremdschlüssel auf den Primärschlüssel dieser Tabelle verweist, rufe ich die Spalte auf PrimaryKeyTable_fk. Auf diese Weise weiß ich, dass wenn ich eine Customer_pkin meiner Kundentabelle und eine Customer_fkin meiner Bestellungstabelle habe, ich weiß, dass sich die Bestellungstabelle auf einen Eintrag in der Kundentabelle bezieht.

Für mich ist dies besonders für Joins sinnvoll, bei denen ich denke, dass es einfacher zu lesen ist.

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk

FWIW, unser neuer Standard (der sich mit jedem neuen Projekt ändert, ich meine "entwickelt") ist:

• Feldnamen der Datenbank in Kleinbuchstaben
• Namen von Großbuchstaben
• Verwenden Sie Unterstriche, um Wörter im Feldnamen zu trennen - konvertieren Sie diese im Code in Pascal-Groß- und Kleinschreibung.
• pk_ Präfix bedeutet Primärschlüssel
• _id Suffix bedeutet eine ganzzahlige ID mit automatischer Inkrementierung
• fk_ Präfix bedeutet Fremdschlüssel (kein Suffix erforderlich)
• _VW Suffix für Ansichten
• is_ Präfix für Boolesche Werte

Also, eine Tabelle mit dem Namen Name kann die Felder hat pk_name_id, first_name, last_name, is_alive,und fk_companyund eine Ansicht genannt LIVING_CUSTOMERS_VW, definiert wie:

SELECT Vorname, Nachname
VON KONTAKTNAMEN
WHERE (is_alive = 'True')

Wie andere bereits gesagt haben, funktioniert fast jedes Schema, solange es konsistent ist und Ihre Bedeutungen nicht unnötig verschleiert.

Ich bin definitiv damit einverstanden, den Tabellennamen in den Namen des ID-Felds aufzunehmen, genau aus den von Ihnen angegebenen Gründen. Im Allgemeinen ist dies das einzige Feld, in das ich den Tabellennamen aufnehmen würde.

Ich hasse den einfachen ID-Namen. Ich bevorzuge es immer, immer die rechnungs-ID oder eine Variante davon zu verwenden. Ich weiß immer, welche Tabelle die maßgebliche Tabelle für die ID ist, wenn ich muss, aber das verwirrt mich

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID 

Was am schlimmsten ist, ist die Mischung, die Sie erwähnen, völlig verwirrend. Ich musste mit einer Datenbank arbeiten, in der es fast immer foo_id war, außer in einer der am häufigsten verwendeten IDs. Das war die Hölle.

Ich bevorzuge DomainName || 'ICH WÜRDE'. (dh Domainname + ID)

DomainName ist oft, aber nicht immer identisch mit TableName.

Das Problem mit der ID allein ist, dass sie nicht nach oben skaliert. Sobald Sie ungefähr 200 Tabellen mit jeweils einer ersten Spalte mit dem Namen ID haben, sehen die Daten alle gleich aus. Wenn Sie ID immer mit dem Tabellennamen qualifizieren, hilft das ein wenig, aber nicht so viel.

Mit DomainName & ID können sowohl Fremdschlüssel als auch Primärschlüssel benannt werden. Wenn Foriegn-Schlüssel nach der Spalte benannt werden, auf die sie verweisen, kann dies eine mnemonische Hilfe sein. Formal ist es nicht erforderlich, den Namen eines Fremdschlüssels mit dem Schlüssel zu verknüpfen, auf den er verweist, da die referenzielle Integritätsbeschränkung die Referenz festlegt. Aber es ist schrecklich praktisch, wenn es darum geht, Abfragen und Updates zu lesen.

Gelegentlich DomainName || 'ID' kann nicht verwendet werden, da in derselben Tabelle zwei Spalten mit demselben Namen vorhanden sind. Beispiel: Employees.EmployeeID und Employees.SupervisorID. In diesen Fällen verwende ich RoleName || 'ID' wie im Beispiel.

Zu guter Letzt verwende ich nach Möglichkeit eher natürliche als synthetische Schlüssel. Es gibt Situationen, in denen natürliche Schlüssel nicht verfügbar oder nicht vertrauenswürdig sind, aber es gibt viele Situationen, in denen der natürliche Schlüssel die richtige Wahl ist. In diesen Fällen lasse ich den natürlichen Schlüssel den Namen annehmen, den er natürlich haben würde. Dieser Name enthält oft nicht einmal die Buchstaben "ID". Beispiel: OrderNo wobei No eine Abkürzung für "Number" ist.

Für jede Tabelle wähle ich eine Baumbuchstabenkürzel (zB Employees => Emp)

Auf diese Weise wird ein numerischer Primärschlüssel für die automatische Nummerierung zu nkEmp .

Es ist kurz, einzigartig in der gesamten Datenbank und ich kenne seine Eigenschaften auf einen Blick genau.

Ich behalte die gleichen Namen in SQL und allen von mir verwendeten Sprachen (meistens C #, Javascript, VB6).

In den Namenskonventionen der Interakt-Site finden Sie ein gut durchdachtes System zum Benennen von Tabellen und Spalten. Die Methode verwendet ein Suffix für jede Tabelle ( _prdfür eine Produkttabelle oder _ctgfür eine Kategorietabelle) und hängt dieses an jede Spalte in einer bestimmten Tabelle an. Die Identitätsspalte für die Produkttabelle wäre id_prdund ist daher in der Datenbank eindeutig.

Sie gehen noch einen Schritt weiter, um das Verständnis der Fremdschlüssel zu erleichtern: Der Fremdschlüssel in der Produkttabelle, der sich auf die Kategorietabelle bezieht, ist idctg_prdso, dass offensichtlich ist, zu welcher Tabelle er gehört (_prd Suffix) und zu welcher Tabelle er sich bezieht (Kategorie). .

Vorteile sind, dass die Identitätsspalten in verschiedenen Tabellen nicht mehrdeutig sind und Sie auf einen Blick erkennen können, auf welche Spalten sich eine Abfrage anhand der Spaltennamen bezieht.

Siehe auch Namenskonvention für Primärschlüssel / Fremdschlüssel

Sie können die folgende Namenskonvention verwenden. Es hat seine Mängel, aber es löst Ihre besonderen Probleme.

1. Verwenden Sie kurze Spitznamen (3-4 Zeichen) für die Tabellennamen, z. B. Invoice - inv, InvoiceLines -invl
2. Benennen Sie die Spalten in der Tabelle , diese Spitznamen verwenden, das heißt inv_id,invl_id
3. Verwenden Sie invl_inv_idfür die Referenzspalten die Namen.

so könnte man sagen

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id