Benennung von ID-Spalten in Datenbanktabellen

Question

Ich Frage mich, Völker Meinungen auf die Nennung von ID-Spalten in Datenbanktabellen.

Wenn ich eine Tabelle namens Rechnungen mit einem primary key eine id-Spalte, die ich nennen würde, die Spalte InvoiceID, so dass ich nicht in Konflikt mit anderen Tischen und es ist offensichtlich, was es ist.

Wo ich bin workind aktuellen Sie nannten alle ID-Spalten-ID.

So würden Sie Folgendes tun:

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

Nun, ich sehe ein paar Probleme hier:
1.Sie müssten alias die Spalten der select -
2.ID = InvoiceID passt nicht in mein Gehirn
3.Wenn Sie nicht alias-Tabellen und bezeichnet InvoiceID ist es offensichtlich, welche Tabelle es ist?

Was sind andere Völker Gedanken zu dem Thema?

Answer 1

ID ist eine SQL-Antipattern.Finden 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 ID als id, die Sie machen, berichten, dass sehr viel schwieriger.Es behindert die Sicht auf Bedeutung und macht komplexe Abfragen schwerer zu Lesen als auch zu dass Sie Aliase verwenden, um zu unterscheiden, auf den Bericht selbst.

Wenn jemand dumm genug ist, zu verwenden eine Natürliche Verknüpfung in einer Datenbank, wo Sie verfügbar sind, Sie zu verbinden, um die falschen Einträge.

Wenn Sie möchten, verwenden Sie die USING-syntax, die einige dbs erlauben, können Sie nicht, wenn Sie mit ID.

Wenn Sie ID können Sie leicht mit einem verwechselt beitreten, wenn Sie passieren zu werden, kopieren Sie die join-syntax (Sag mir nicht, dass niemand jemals tut dies!)und vergessen Sie zum ändern der alias in der join-Bedingung.

So haben Sie 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

wenn Sie gedacht

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, diese Art von unbeabsichtigter Fehler, ist weit weniger wahrscheinlich zu geschehen, und viel einfacher zu finden.

Answer 2

Ich habe immer bevorzugt ID TableName + ID für die id-Spalte und dann TableName + ID für einen Fremdschlüssel.Auf diese Weise werden alle Tabellen haben die gleichen Namen für die id-Feld und das gibt es nicht eine redundante Beschreibung.Dies scheint einfacher für mich, weil alle Tabellen den gleichen Primärschlüssel-Feld-Namen.

So weit wie das verknüpfen von Tabellen und wissen nicht, welche Id das Feld gehört dem Tisch, in meiner Meinung nach die Abfrage geschrieben werden soll, um mit dieser situation umzugehen.Wo ich arbeite, haben wir immer prefece die Felder, die wir verwenden, in einer Erklärung mit der Tabelle/table alias.

Answer 3

Theres in meinem Unternehmen in der letzten Zeit ein Nerd Kampf um diese Sache gewesen. Das Aufkommen von LINQ hat die entlassenen name + ID Muster noch offensichtlich dumm in meinen Augen. Ich denke, die meisten vernünftigen Leute werden sagen, dass, wenn Sie die Hand Schreiben der SQL in einer solchen Art und Weise sind, wie, dass Sie Tabellennamen angeben müssen, unterscheiden FKs dann ist es nicht nur Einsparungen bei der Eingabe, aber es fügt Klarheit zu Ihrer SQL nur die ID in das verwenden Sie deutlich sehen können, welche die PK und das ist, ist die FK .

z.

FROM Employees e     LEFT JOIN Kunden c ON e.ID = c.EmployeeID

sagt mir nicht nur, dass die beiden miteinander verbunden sind, aber das ist die PK und das ist der FK . Während im alten Stil sind Sie gezwungen, entweder zu suchen oder hoffen, dass sie auch genannt wurden.

Answer 4

Wir verwenden InvoiceID, nicht ID. Es macht Abfragen besser lesbar -., Wenn Sie ID sehen allein es alles bedeuten könnte, vor allem wenn Sie die Tabelle alias i

Answer 5

Ich bin mit Keven und ein paar andere Leute hier, dass die PK für eine Tabelle einfach Id und Fremdschlüssel sein sollte, die OtherTable + ID-Liste.

Allerdings möchte ich einen Grund hinzuzufügen, die in letzter Zeit mehr Gewicht auf diese arguement gab.

In meiner aktuellen Position, die wir beschäftigen, die Entity Framework POCO Generation verwenden. Mit dem Standard-Namenskonvention von Id der die PK für die Vererbung einer Base poco Klasse ermöglicht mit Validierung und solche für Tabellen, die eine Reihe von gemeinsamen Spaltennamen teilen. Mit Hilfe der Tablename + Id wie die PK für jede dieser Tabellen zerstört die Fähigkeit, eine Basisklasse für diese zu verwenden.

Sie einfach ein wenig zu denken.

Answer 6

Es ist nicht wirklich wichtig, sind Sie wahrscheinlich in simalar Probleme in allen Namenskonventionen laufen.

Aber es ist wichtig, konsequent zu sein, so dass Sie auf die Tabelle schauen, um Definitionen nicht jedes Mal, wenn Sie eine Abfrage schreiben.

Answer 7

Meine Präferenz ist auch ID für Primärschlüssel und TableNameID für Fremdschlüssel. Ich mag auch in den meisten Tabellen eine Spalte „Name“ haben, wo ich den Benutzer lesbare Kennung (das heißt Name :-)) des Eintrags halten. Diese Struktur bietet eine große Flexibilität in der Anwendung selbst, ich Tabellen in Masse, in gleicher Weise behandeln kann. Dies ist eine sehr mächtige Sache. Normalerweise wird eine OO-Software auf der Datenbank aufgebaut, aber der OO-Toolset kann nicht angewandt werden, da der db nicht selbst es zulassen. die Spalten-ID und den Namen zu haben, ist noch nicht sehr gut, aber es ist ein Schritt.

  

Wählen Sie
      i.ID, il.ID Aus       Rechnungen i       LEFT JOIN InvoiceLines il           auf i.ID = il.InvoiceID

Warum kann ich das tun?

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

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

Answer 8

Ich habe gerade angefangen an einem Ort arbeiten, die nur „ID“ (in den Kerntabellen verwiesen wird durch TableNameID in Fremdschlüssel) verwendet und habe bereits zwei Produktionsprobleme direkt verursacht werden.

In einem Fall die Abfrage verwendet "... wo ID in (ID FROM OtherTable SELECT ..." statt "... wo ID in (SELECT TransID FROM OtherTable ...".

Kann jemand ehrlich sagen, das wäre nicht viel einfacher gewesen zu erkennen, wenn eine vollständige und dauerhafte Namen verwendet wurden, in denen die falsche Aussage hätte lesen „... wo TransID in (SELECT OtherTableID von OtherTable ...“? I don ‚t denken so.

Das andere Problem tritt auf, wenn Code Refactoring. Wenn Sie eine temporäre Tabelle, während zuvor die Abfrage ging eine Kerntabelle dann der alte Code liest „... dbo.MyFunction (t.ID) ...“ und wenn das nicht geändert wird, aber ‚t‘ bezieht sich nun auf ein temp-Tabelle anstelle der Kerntabelle, Sie haben nicht einmal einen Fehler -. nur fehlerhafte Ergebnisse

Wenn unnötige Fehler zu erzeugen, ist ein Ziel (vielleicht einige Leute nicht genug Arbeit?), Dann ist diese Art Konvention der Namensgebung ist groß. Ansonsten konsistente Namensgebung ist der Weg zu gehen.

Answer 9

Aus Gründen der Einfachheit der meisten Leute nennen Sie die Spalte auf dem Tisch ID. Wenn es einen Fremdschlüssel Bezug auf eine andere Tabelle hat, dann explizit nennen sie es InvoiceID (Ihr Beispiel zu verwenden) im Fall verbindet, sind Sie in der Tabelle ohnehin Aliasing so die explizite inv.ID ist noch einfacher als inv.InvoiceID

Answer 10

bei diesem Aus der Perspektive eines formalen Daten Wörterbuch, würde ich das Datenelement invoice_ID nennen. Im Allgemeinen wird ein Datenelementname im Data Dictionary eindeutig sein und idealerweise die gleichen Namen in ganz hat, obwohl manchmal zusätzliche Qualifizierungsvoraussetzungen erforderlich basierend auf Kontexte können z.B. das Datenelement könnte namens employee_ID jeweils als supervisor_employee_ID subordinate_employee_ID und zweimal in dem Organigramm und damit qualifiziert verwendet werden.

Offensichtlich Namenskonventionen sind subjektiv und eine Frage des Stils. Ich habe ISO / IEC 11179 Richtlinien finden ein nützlicher Ausgangspunkt sein.

Für das DBMS, ich sehe Tabellen als Sammlungen von Entities (mit Ausnahme derjenigen, die je nur eine Zeile enthalten zum Beispiel cofig Tabelle, Tabelle von Konstanten, usw.) z.B. der Tisch, an dem mein employee_ID den Schlüssel ist, würde den Name Personnel. So sofort die TableNameID Konvention für mich nicht funktioniert.

Ich habe den TableName.ID=PK TableNameID=FK Stil auf großen Datenmodellen gesehen und muß sagen, ich finde es etwas verwirrend: ich viel lieber eine Kennung Namen gleich seine ganzen dh Namen nicht basierend auf Änderung, die Tabelle kommt es in erscheinen. etwas zu beachten ist, die zuvor erwähnte Art scheint in den Geschäften, die eine IDENTITY (Autoinkrement) Spalte auf alle Tabelle hinzufügen verwendet werden, während natürliche und Verbindung Schlüssel in Fremdschlüssel meidet. Diese Geschäfte sind in der Regel nicht formale Daten Wörterbücher haben noch von Datenmodellen zu bauen. Auch dies ist nur eine Frage des Stils und eine, auf die ich persönlich nicht abonnieren. Also letztendlich, es ist nicht für mich.

Alles, was gesagt, ich die Qualifikation aus dem Spaltennamen für manchmal fällt einen Fall sehen kann, wenn die Name der Tabelle zu tun, so zum Beispiel eines Kontext liefert das Element mit dem Namen employee_last_name einfach in der last_name Tabelle Personnel werden könne. Der Grund ist, dass die Domain ‚Volks Nachnamen‘ und ist eher mit UNION Spalten von andere Tabellen anstatt verwendet werden als Fremdschlüssel in andere last_nameed werden Tisch, aber dann wieder ... ich kann nur meine Meinung ändern, manchmal kann man nie wissen. Das ist die Sache: Datenmodellierung ist teils Kunst, teils Wissenschaft

.

Answer 11

I persönlich bevorzugen (wie es oben erwähnt wurde) die Table.ID für die PK und TableID für die FK . Auch (bitte schießen mir nicht) Microsoft Access dies empfiehlt.

Aber ich weiß auch, für eine Tatsache, dass einige Erzeugungs Werkzeuge, um die TableID für PK bevorzugen, weil sie dazu neigen, alle Spaltennamen zu verknüpfen, die ‚ID‘ im Wort enthalten, EINSCHLIESSLICH ID! !!

Auch die Abfrage-Designer tut dies auf Microsoft SQL Server (und für jede Abfrage, die Sie erstellen, Sie am Ende alle unnötigen neu geschaffenen Beziehungen auf allen Tabellen auf Spalte ID Abreißen)

DAMIT so viel wie meine innere OCD hasst es, ich rolle mit der TableID Konvention. Erinnern wir uns daran, dass es eine Daten BASE genannt, da es die Basis für hoffentlich viele viele viele Anwendungen sein zu kommen. Und alle Technologien sollten mit klaren Beschreibung Schema eines gut normalisierte profitieren.

Es ist selbstverständlich, dass ich meine Linie zeichne, wenn die Menschen mit Tablename, TableDescription und so starten. Meiner Meinung nach sollten Konventionen wie folgt vor:

• Tabellenname: Pluralisierung. Ex. Mitarbeiter

• Table Alias: Volltabellenname, vereinzelte. Bsp.

  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
  

[Update]

Auch gibt es einige gültigen Beiträge in diesem Thread über dupliziert Spalten aufgrund der „Art der Beziehung“ oder Rolle. Beispiel: Wenn ein Shop ein hat EmployeeID , das sagt mir gedrungen. Also ich manchmal so etwas wie Store.EmployeeID_Manager . Sicher ist es ein bisschen größer, aber bei leas Leute zu finden nicht verrückt werden versuchen Tabelle ManagerID , oder was EmployeeID es tut. Beim Abfragen ist, wo ich vereinfachen würde es als:     SELECT EmployeeID_Manager als ManagerID FROM Speicher

Answer 12

Ich glaube, Sie etwas für die „ID“ verwenden können, solange Sie konsistent sind. die Tabellennamen einschließlich wichtig ist. Ich würde vorschlagen, ein Modellierungswerkzeug wie Erwin mit den Namenskonventionen und Standards so zu erzwingen, wenn Abfragen zu schreiben, es ist einfach, die Beziehungen zu verstehen, die zwischen Tabellen existieren.

Was ich durch die erste Aussage meine, statt ID Sie etwas anderes wie ‚recno‘ verwenden können. Also dann würde diese Tabelle eine PK von invoice_recno hat und so weiter.

Cheers, Ben

Answer 13

Meine Stimme ist für InvoiceID für die Tabellen-ID. Ich benutze auch die gleiche Namenskonvention, wenn es als Fremdschlüssel verwendet wird und in den Abfragen intelligenten Alias-Namen verwendet werden.

 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ächeln. Dies ist für die Nachwelt und einen Tag, ein armer junior Coder ist zu haben, Ihr Meisterwerk zu ändern. In diesem Beispiel gibt es keine Zweideutigkeit und als zusätzliche Tabellen für die Abfrage hinzugefügt bekommen, können Sie für die Ausführlichkeit dankbar sein werden.

Answer 14

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

Wenn ich die Felder in eine unbenannte struct über LINQ zu kopieren, ich kann es nennen „ID“ gibt, wenn es die einzige ID in der Struktur ist.

Wenn die Spalte nicht in einem Fremdschlüssel verwendet werden soll, so dass es nur eine Zeile für bearbeiten Bearbeiten oder Löschen zur eindeutigen Identifizierung verwendet wird, werde ich es nennen „PK“.

Answer 15

Wenn Sie geben jedem Schlüssel einen eindeutigen Namen, beispielsweise „Invoices.invoice_id“ anstelle von „invoices.id“, dann können Sie mit dem „natürlichen Join“ und „mit“ Betreiber ohne Sorgen. Z.

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

statt

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

SQL ist die ausführliche genug ohne es ausführlicher zu machen.

Answer 16

Was ich tue Dinge konsistent zu halten für mich (wo eine Tabelle, die eine einzelne Spalte Primärschlüssel als ID verwendet) ist der Primärschlüssel der Tabelle Table_pk zu nennen. Überall habe ich einen fremden Schlüssel auf diesen Tabellen Primärschlüssel, ich nenne die Spalte PrimaryKeyTable_fk. Auf diese Weise weiß ich, dass, wenn ich eine Customer_pk in meiner Customer-Tabelle und eine Customer_fk in meiner Order-Tabelle habe, ich weiß, dass die Order-Tabelle in der Customer-Tabelle auf einen Eintrag bezieht.

Für mich das macht Sinn besonders für Joins, wo ich denke, es liest einfacher.

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

Answer 17

FWIW, unsere neuen Standard (die sich ändert, äh, ich meine "entwickelt sich" mit jedem neuen Projekt) ist:

• Kleinbuchstaben Datenbank-Feldnamen
• Versalien- Tabellennamen
• Verwenden Sie Wörter unterstreicht im Feldnamen zu trennen -. Konvertieren diese Pascal Fall in Code
• pk_ Präfix bedeutet Primärschlüssel
• _id Suffix bedeutet eine ganze Zahl, Autoinkrement-ID
• fk_ Präfix bedeutet Fremdschlüssel (kein Suffix erforderlich)
• _VW Suffix für Ansichten
• is_ Präfix für booleans

Also, eine Tabelle mit dem Namen NAMES haben könnte die Felder pk_name_id, first_name, last_name, is_alive, und fk_company und eine Ansicht namens LIVING_CUSTOMERS_VW, definiert wie:

SELECT first_name, last_name
FROM CONTACT.NAMES
WHERE (is_alive = 'True')

Wie andere gesagt haben, aber fast jede Regelung wird so lange arbeiten, wie es konsistent ist und nicht unnötig Ihre Bedeutungen verschleiern.

Answer 18

Ich stimme definitiv mit einschließlich der Tabellennamen in dem ID-Feldnamen, für genau die Gründe, die Sie geben. Im Allgemeinen ist dies der einzige Bereich, in dem ich die Tabellennamen enthalten würde.

Answer 19

Ich hasse tun die Ebene id Namen. Ich ziehe es stark zu immer davon die invoice_id oder eine Variante 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 ist das Schlimmste von allem ist die Mischung Sie erwähnen, total verwirrend. Ich habe mit einer Datenbank arbeiten musste, wo fast immer es war, außer in eines der am häufigsten verwendeten ids foo_id. Das war total hell.

Answer 20

Ich ziehe Domänenname || 'ICH WÜRDE'. (D Domänenname + ID)

Domänenname ist oft, aber nicht immer, die gleiche wie Tablename.

Das Problem mit ID wie von selbst, dass es nicht nach oben skaliert. Sobald Sie über 200 Tabellen, die jeweils mit einer ersten Spalte mit dem Namen ID beginnen die Daten alle gleich aussehen. Wenn Sie immer ID mit dem Tabellennamen qualifizieren, das hilft ein wenig, aber nicht so viel.

Domänenname & ID kann Fremdschlüssel verwendet werden, zu nennen sowie Primärschlüssel. Wenn foriegn Schlüssel nach der Spalte mit dem Namen sind, dass sie verweisen kann, dass von mnemonic Hilfe sein. Formal ist ein Fremdschlüssel auf die Schlüssel es Referenzen den Namen der Bindung nicht notwendig, da die referentielle Integrität constrain wird die Referenz etablieren. Aber es ist furchtbar praktisch, wenn es um das Lesen von Abfragen und Updates kommt.

Gelegentlich Domänenname || ‚ID‘ kann nicht verwendet werden, weil es zwei Spalten in derselben Tabelle mit dem gleichen Namen sein würde. Beispiel: Employees.EmployeeID und Employees.SupervisorID. In diesen Fällen verwende ich Rolename || 'ID', wie im Beispiel.

Last but not least, verwende ich natürlichen Schlüssel anstatt synthetische Schlüssel, wenn möglich. Es gibt Situationen, in denen natürliche Schlüssel nicht verfügbar sind oder nicht vertrauenswürdig, aber es gibt viele Situationen, in denen die natürlichen Schlüssel die richtige Wahl ist. In diesen Fällen ließ ich die natürlichen Schlüssel nehmen auf den Namen es natürlich haben würde. Dieser Name wird oft nicht einmal die Buchstaben haben, ‚ID‘ drin. Beispiel: OrderNo wo keine ist eine Abkürzung für „Number“.

Answer 21

Für jede Tabelle wähle ich einen Baum Brief Stenografie (z. Mitarbeiter => Emp)

Auf diese Weise ein numerischer Autowert Primärschlüssel wird nkEmp .

Es ist kurz, einzigartig in der gesamten Datenbank und ich weiß genau, seine Eigenschaften auf einem Blick.

ich immer wieder die gleichen Namen in SQL und alle Sprachen, die ich verwende (meistens C #, Javascript, VB6).

Answer 22

Sehen Sie die Interakt Website Namenskonventionen für ein gut durchdachtes System von Tabellen und Spalten zu benennen. Das Verfahren nutzt ein Suffix für jede Tabelle (_prd für ein Produkt Tabelle oder _ctg für eine Kategorietabelle) anhängt und daß an jede Spalte in einer Tabelle. So ist die Identitätsspalte für die Produkttabelle id_prd werden würde, und ist daher einzigartig in der Datenbank.

Sie gehen noch einen Schritt weiter mit Verständnis der Fremdschlüssel zu helfen: Der Fremdschlüssel in der Produkttabelle, die so idctg_prd würde in die Kategorie Tabelle verweist, dass es offensichtlich ist, auf die Tabelle, um sie (_prd Suffix) gehören und zu denen Tabelle es bezieht sich (Kategorie).

Die Vorteile sind, dass es keine Zweideutigkeit mit den Identitätsspalten in verschiedenen Tabellen ist, und dass Sie auf einen Blick erkennen können, welche Spalten eine Abfrage durch die Spaltennamen eingegeben werden.

Answer 23

siehe auch Primärschlüssel / Fremdschlüssel Namenskonvention

Answer 24

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

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

Auf diese Weise könnte man sagen

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id