Benennung von ID-Spalten in Datenbanktabellen


97

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?


1
Argh, wir sind umgeben von Leuten mit schlechtem Geschmack! ;-)
Vinko Vrsalovic


2
Wie wäre es mit der Auswahl der zweiten Antwort als " die Antwort "?
Anzeigename

Mögliches Duplikat des Namensschemas für
Fremdschlüssel

Antworten:


23

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.


8
@ spencer7593, nur weil du ID magst, heißt das nicht, dass es kein Antimuster ist. Es ist schwieriger, Fehler in Verknüpfungen zu machen, wenn Sie die Tabellennamen-ID haben, da Sie sofort einen Syntaxfehler erhalten würden.
HLGEM

6
+1 Spalten, die synonym sind, sollten denselben Namen haben. Wenn Sie das Tabellennamenpräfix verwenden, können Sie eine Primärschlüsselspalte mit dem Namen table1ID und eine Fremdschlüsselspalte in einer anderen Tabelle mit dem Namen table1ID haben. Sie wissen, dass sie dasselbe sind. Das wurde mir vor 20 Jahren beigebracht und es ist eine Praxis, die dich nicht im Stich lässt.
Amelvin

9
NEIN! Dies ist die Schlumpf-Namenskonvention!
Ross

19
Diese Konvention gefällt mir nicht, weil Sie praktisch gezwungen sind, alle Ihre Tabellen zu aliasen, damit Sie die Tabelle nicht redundant benennen, die Tabelle erneut benennen und dann die ID hinzufügen. join table2 on table1.table1id = table2.table1id. Ihre Argumentation ist in Ordnung, außer dass bei Verwendung der ID der Name der Tabelle ohnehin vor der ID steht. join table2 on table1.id = table2.table1id... was genauso ausführlich und nicht redundant ist und auch keine obskuren Aliase erzwingt, um die gerade erwähnte Redundanz zu verhindern .. was meiner Meinung nach der Fluch der SQL-Entwicklung ist.
Anther

13
Wenn Sie dann ein NameFeld in einer Tabelle haben, sollten Sie es ändern Table1Name, um dieselben Probleme mit diesem Feld zu vermeiden? Sollten Sie aus demselben Grund allen Spalten den Tabellennamen voranstellen? Das klingt nicht richtig.
Joanvo

151

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.


2
Ich erkenne einen alten Thread, aber ich stimme zu. Erleichtert auch die Zuordnung auf der Datenzugriffsebene: Wenn alle "Objekte" ein ID-Feld haben, das eindeutig sein muss, können Sie sie generisch machen, wenn Sie Methoden auf der Datenzugriffsebene erstellen, um beispielsweise Elemente zu löschen, da Sie eine Liste von erhalten können IDs für alles und wissen, dass Sie nur löschen müssen, wobei Id = blah aus dieser bestimmten Tabelle, anstatt eine Zuordnung der für jede Tabelle eindeutigen Elemente sowie die Zuordnung von Tabellenname / Programmlogikname beizubehalten.
Mike

1
Kevin, genau wie du. Beispiel: Benutzer-ID, Rollen-ID für PKey und Rollen-Benutzer-ID für FKey. Es ist gut für ein Großprojekt. Denn wenn alle ID-Felder mit "id" benannt sind, ist dies zu verwirrend. Aber ich denke, es ist eine persönliche Präferenz, jemand denkt, nur "id" zu verwenden, ist klar.
Cheung

2
Das ist meine Präferenz. Nur weil tabellenübergreifende Abfragen schwieriger zu lesen sind, bedeutet dies nicht, dass die ID-Spalte geändert werden sollte, um dies zu vereinfachen. Machen Sie einfach Ihre Aliase aussagekräftiger.
Mutton

1
Ich vermute, dass die Konvention, der ID einen Entitätsnamen voranzustellen, von Personen stammt, die aus irgendeinem Grund "select * from" verwenden. In einer Umgebung, die "select *" toleriert, wird die Realität normalerweise verzerrt, um die Massenauswahl von allem von überall zu unterstützen. Macht nicht viel Sinn, wenn Sie nicht alles blind auswählen. Es gibt auch Verweise auf USING und natürliche Verknüpfungen, die ziemlich gefährlich sind und für mich überhaupt nicht als Argument erscheinen, da sie Sie effektiv daran hindern, rollenbasierte Fremdschlüssel-Namenskonventionen zu verwenden.
Roman Polunin

53

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.


2
Außer ich habe noch nie in meinem Leben einen einzigen Entwickler gekannt, der Ihr Beispiel schreibt. Sie schreiben stattdessen: LEFT JOIN Kunden als c ON e.ID = c.EmployeeID Für mich ist dies klarer: LEFT JOIN Kunden als c ON e.EmployeeID = c.EmployeeID Und welches Element der Fremdschlüssel ist, ist am Tabellennamen ersichtlich . offensichtlich ist customer.employeeId ein Fremdschlüssel, employee.employeeId jedoch nicht.
Dallas

7
Viele Leute (wie Berichtersteller, die sehr komplexe SQL-Dateien schreiben) und BI-Spezialisten, die Importe und Exporte ausführen, müssen SQl noch handschriftlich schreiben. Das Datenbankdesign muss sie auch berücksichtigen, nicht nur Anwendungsentwickler.
HLGEM

29

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.


Stimmen Sie zu, und Sie weisen auf den Hauptgrund hin, warum "id" nicht verwendet wird, da wir immer Tabellenalias wie "i" für inoice, p für "product" in SQL oder LINQ usw. haben.
Cheung

2
Die Verwendung von Id ist besser geeignet. Die Spalte befindet sich in der Tabelle "Rechnungen", so dass dies ausreichen sollte. Wenn Sie tabellenübergreifende Abfragen schreiben, sollten Sie aussagekräftigere Aliase verwenden. "i" ist nicht genug. Nennen Sie es "Rechnungen".
Mutton

1
Es ist nicht klar, dass "ID" allein Rechnungen bedeutet. Angenommen, Sie haben auch Fremdschlüssel für Konten und Personen. Welches ist nun "ID"? Ist es in einem Join nicht einfacher, beispielsweise a.InvoiceID = b.InvoiceID anstelle von a.ID = b.InvoiceID zu lesen und es nicht einfach zu debuggen?
Jason Cohen

22

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.


8
+1 für ein Beispiel aus der Praxis, wie generische Namen die Wiederverwendung von Code in bestimmten Fällen verbessern (das wird vielen Entwicklern wichtig sein, da es Millionen von .NET-Entwicklern gibt und viele EF verwenden).
Codingoutloud

Nicht nur EF und dergleichen bei meiner Arbeit haben wir viele generische Methoden. Ein Webservice hat also so etwas wie List <Ergebnis> Speichern <T> (List <int> IDs); Da wir wissen, dass jede Tabelle eine ID-Spalte hat, die der Primärschlüssel ist, können wir solche Dinge mit nur einer einfachen Zuordnung von C # -Objekten zu ihren Tabellen tun (z. B. <Kunde, "Kunden">, <BillingCode, "BillingCodes"> ( oder besser noch gespeicherte Prozessnamen), generieren Sie die SQL im laufenden Betrieb basierend auf dem übergebenen Objekt und voila keine wiederholten Methoden zum Speichern / Löschen / Bearbeiten für jeden Objekttyp.
Mike

11

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.


10

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.


8

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.


3
+1 für ein Beispiel aus der Praxis für einen spezifischeren Namen, der die Wartbarkeit verbessert.
Codingoutloud

6

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


6

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


Ich denke, Ihr Standpunkt ist gut für die Schönheit und die didaktischen Zwecke der Datenbank, aber für die Funktionalität halte ich es für ein Problem. Mehrere Tabellennamen fördern die Inkonsistenz zwischen Tabellen und PK-ID. <-> FK IdTable erzeugt Unterschiede im Namen derselben Sache. Gleichzeitig ist es etwas User.UserIdseltsam , etwas in die Programmierung einzutippen.
Machado

4

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.


2

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


2

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.


1

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.


1

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.


Wissen Sie, ob SQL Server Natural Join unterstützt?
Arry

Ich glaube nicht, dass es so ist. Laut connect.microsoft.com/SQLServer/feedback/… scheint die Syntax in einer bestimmten Version nach SQL Server 2005 hinzugefügt zu werden. Ich weiß, dass sie in PostgreSQL und in Oracle funktioniert.
Steven Huwig

7
Verwenden Sie niemals, niemals, niemals natürliche Verbindungen. Wenn eine Tabelle beim Schreiben der Abfrage ein Beschreibungsfeld enthält, ist dies in Ordnung. Wenn später jemand der anderen Tabelle ein Beschreibungsfeld hinzufügt, werden Sie ebenfalls daran teilnehmen und vollständig brechen.

1
heh, das klingt wie der Klang der realen Erfahrung :)
dland

Ich würde Natural Join nur für Ad-hoc-Abfragen verwenden.
Steven Huwig

1

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

1

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.


0

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.


0

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.


1
Ich habe das Wort "Rechnung" in diesem Beitrag zu oft gelesen. Es sieht jetzt lustig aus
Kevin

2
Ugh, implizite Joins! Ich möchte meine Augäpfel herausreißen, wenn ich mir das ansehe.
HLGEM

0

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.


0

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).


0

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.



-2

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

5
ick! Ich würde gegen die Verwendung kurzer Spitznamen für Tabellen (oder andere Objekte) stimmen. Mit Spitznamen wissen Sie nie genau, wie der Kurzname lautet. Denken Sie daran, es gibt viele Möglichkeiten, es falsch zu buchstabieren. Es gibt nur einen Weg, es richtig zu buchstabieren.
James Curran

1
James, ich bin anderer Meinung. Wenn Sie einen Kurznamen haben, der nicht beschreibend ist, und sich nicht erinnern können, was er ist, haben Sie den falschen Namen ausgewählt oder verstehen die von jemand anderem gewählte Namenskonvention nicht.
kemiller2002

2
Verwenden Sie Aliase, um den gleichen Effekt zu erzielen. Wählen Sie * von Invoice inv left join InvoiceLines invl on inv.ID = invl.InvoiceID
yfeldblum

2
Nein nein Nein Nein. Alias ​​die Tabelle mit einem Abrievation in der Abfrage. Der Tabellenname sollte jedoch vollständig sein.
Mesh

2
Warum sind so viele Programmierer faul und scheinen die Antwort auf alles zu sein, möglichst wenig zu tippen, nur weil es zu schwierig ist, ein bisschen mehr zu tippen.
mP.
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.