Namenskonventionen für Datenbanken, Tabellen und Spalten?

Ich empfehlen, Check-out von Microsoft SQL Server-Beispieldatenbanken:
https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

Die AdventureWorks-Beispieldatenbank verwendet eine sehr klare und konsistente Namenskonvention, anhand der schema-Namen, die für die Organisation der Datenbank-Objekte.

1. Einzigartigen Namen für Tabellen
2. Einzigartigen Namen für Spalten
3. Schema-Namen für Tabellen-prefix (E. g.: SchemeName.TableName)
4. Pascal Gehäuse (.k.ein. upper-camel-case)

InformationsquelleAutor der Antwort urini

Ok, da sind wir bei einem Gewicht mit der Meinung:

Ich glaube, dass die Tabellennamen werden sollte, plural. Tabellen sind eine Sammlung (eine Tabelle) von Entitäten. Jede Zeile eine Einheit darstellt, und die Tabelle stellt die Sammlung. So würde ich eine Tabelle von Person Personen Personen (oder Personen, was immer Ihr Lust und Laune).

Für diejenigen, die gerne sehen, singular "entity names" in Abfragen, das ist, was ich verwenden würde-Tabelle aliases:

SELECT person.Name
FROM People person

Etwas wie LINQ "von der person im Menschen, die person auswählen.Namen".

Als für 2, 3 und 4, Stimme ich mit @Lars.

InformationsquelleAutor der Antwort Matt Hamilton

1. Nicht. Eine Tabelle sollte den Namen der Entität, die es repräsentiert.
   Person, keine Personen, wie Sie finden würde, wen man von den Datensätzen repräsentiert werden.
2. Wieder die gleiche Sache. Die Spalte FirstName wirklich sollte nicht als Vornamen. Es hängt alles davon ab, was Sie wollen, Sie zu vertreten mit der Spalte.
3. KEINE.
4. Ja. Fall für Klarheit. Wenn Sie brauchen, um Spalten wie "Vorname", Gehäuse machen es leichter zu Lesen.

Ok. Das ist meine $0,02

InformationsquelleAutor der Antwort Lars Mæhlum

unsere Präferenz:

1. Sollte Tabellennamen werden im plural?
   
   Nie. Die Argumente, die für Sie eine Sammlung sinnvoll, aber man weiß ja nie, was die Tabelle ist enthalten (0,1 oder viele Artikel). Plural-Regeln machen die Benennung unnötig kompliziert. 1 Haus, 2 Häuser, Maus, gegen Mäuse, person, gegen Leute, und wir haben noch nicht einmal angeschaut, alle anderen Sprachen.

   Update person set property = 'value' wirkt auf jede person in der Tabelle.
   
   Select * from person where person.name = 'Greg' gibt eine Sammlung/rowset person Zeilen.

2. Sollten die Spaltennamen werden im singular?
   
   Normalerweise ja, es sei denn, Sie brechen Normalisierung Regeln.

3. Sollte ich die Präfix-Tabellen oder Spalten?
   
   Meist ein Plattform-Präferenz. Wir bevorzugen Präfix Spalten mit dem Tabellennamen. Wir nicht-Präfix-Tabellen, aber wir tun Präfix Ansichten (v_) und stored_procedures (sp_ oder f_ (function)). Das hilft Menschen, die versuchen möchten, upday v_person.Alter, das ist tatsächlich ein berechnetes Feld in einer Ansicht (die kann nicht Aktualisiert werden, sowieso).

   Es ist auch ein guter Weg, um zu vermeiden, keyword-Kollision (die Lieferung.aus Pausen, aber delivery_from nicht).

   Es macht den code Ausführlicher ist, aber oft aids in der Lesbarkeit.

   bob = new person()

bob.person_name = 'Bob'

bob.person_dob = '1958-12-21'
   
   ... ist sehr gut lesbar und explizit. Dies kann aus der hand, obwohl:

   customer.customer_customer_type_id

   zeigt eine Beziehung zwischen dem Kunden und der customer_type Tabelle zeigt die Primärschlüssel der customer_type Tabelle (customer_type_id) und wenn Sie jemals 'customer_customer_type_id' während dem Debuggen einer Abfrage, die Sie sofort wissen, wo es ist aus dem (Kunden-Tabelle).

   oder wo haben Sie die M-M Beziehung zwischen customer_type und customer_category (nur bestimmte Typen sind erhältlich, um bestimmte Kategorien)

   customer_category_customer_type_id

   ... ist ein wenig (!) auf der langen Seite.

4. Sollte ich jedem Fall bei der Benennung von Objekten?
   Ja - Kleinschreibung :), mit Unterstrichen. Diese sind sehr gut lesbar und cross-Plattform. Zusammen mit den 3 oben genannten ist es auch sinnvoll.

   Meistens sind diese Vorlieben aber. - So lange wie Sie konsistent sind, sollte es vorhersehbar für jeden, es zu Lesen.

InformationsquelleAutor der Antwort Albert

Höre ich das argument die ganze Zeit, ob oder nicht eine Tabelle ist pluralisiert ist alles eine Frage des persönlichen Geschmacks, und es gibt keine best-practice. Ich glaube nicht, das ist wahr, vor allem als Programmierer, im Gegensatz zu einem DBA. Soweit ich informiert bin, gibt es keine legitimen Gründe, in den Plural eine Tabelle anderen Namen als "Es macht einfach Sinn für mich, weil es eine Sammlung von Objekten," während es legitim Gewinne im code durch einzigartige Tabellennamen. Zum Beispiel:

1. Vermeidet es bugs und Fehler, verursacht durch plural zu Unklarheiten. Programmierer sind nicht gerade bekannt für Ihre Rechtschreib-know-how und pluralizing einige Wörter sind verwirrend. Zum Beispiel, ist die plural-Wort-Ende 'es' oder nur 's'? Ist es Personen oder Menschen? Wenn Sie an einem Projekt arbeiten mit großen teams, dies kann zu einem Problem werden. Zum Beispiel, eine Instanz, wo ein team-Mitglied nutzt die falsche Methode, um den Plural einer Tabelle, die er schafft. Durch die Zeit, die ich interagieren mit dieser Tabelle, es ist verwendet überall im code, den ich keinen Zugriff habe oder würde zu lange dauern zu beheben. Das Ergebnis ist, ich habe zu erinnern, um Zauber die Tabelle falsch, jedes mal ich es verwenden. Etwas sehr ähnliches passiert mir das. Je einfacher Sie es machen können, für jedes Mitglied des Teams, konsequent und leicht zu verwenden, um die genauen, richtigen Tabellennamen ohne Fehler oder mit look-up-Tabelle Namen, desto besser. Die singular-version ist viel einfacher zu handhaben in einer team-Umgebung.

2. Wenn Sie die singular-version den Namen einer Tabelle UND stellen Sie den primär-Schlüssel (mit dem Namen der Tabelle, haben Sie jetzt den Vorteil, leicht zu bestimmen, eine Tabelle aus einer primary key-oder Umgekehrt über den code alleine. Sie können gegeben werden, eine variable mit einer Tabelle Namen, verketten, "Id" am Ende, und Sie haben jetzt den Primärschlüssel von der Tabelle per code, ohne eine zusätzliche Abfrage. Oder Sie können schneiden Sie "Id" aus dem Ende des einen primary key zu bestimmen, den Namen einer Tabelle per code. Wenn Sie "id", ohne den Namen einer Tabelle für den Primärschlüssel, dann kann man nicht per code bestimmen Sie den Namen der Tabelle aus der Primärschlüssel. Außerdem, die meisten Leute, die den Plural für Tabellennamen und Präfix PK Spalten mit dem Tabellennamen verwenden Sie die singular-version der name der Tabelle in der PK (z.B. Status und statusId), macht es unmöglich, das zu tun.

3. Wenn Sie den Tabellennamen in der Einzahl, Sie können Sie haben, entsprechen die Namen der Klassen, die Sie vertreten. Noch einmal, dies vereinfacht den code und erlauben Ihnen zu tun, wirklich nette Dinge, wie z.B. die Instanziierung einer Klasse, die nichts, aber der name der Tabelle. Es auch, nur lässt sich der code mehr konsistent, was führt zu...

4. Wenn Sie den Tabellennamen in der Einzahl, es macht Ihr Namensschema konsequent, organisiert und leicht zu pflegen in jeder Lage. Sie wissen, dass in jedem Fall in deinem code, ob es in eine Spalte name, als der name einer Klasse, oder wie der name der Tabelle, es ist die gleiche genaue Bezeichnung. Dies ermöglicht Ihnen die Globale Suche zu sehen, überall, wo Daten verwendet werden. Wenn Sie den Plural von Namen einer Tabelle, es wird Fälle geben, wo Sie die singular-version, die Tabellennamen (die Klasse verwandelt sich in, in den primär-Schlüssel). Es macht einfach Sinn, um nicht einige Fälle, in denen Ihre Daten bezeichnet man als plural und einige Instanzen singular.

Um es zusammenzufassen, wenn Sie in den Plural Ihrer Tabelle die Namen, die Sie verlieren alle Arten von Vorteile, um Ihren code intelligenter und einfacher zu handhaben. Es kann sogar Fälle geben, wo Sie haben, um lookup-Tabellen/arrays zu konvertieren Sie Ihre Tabelle von Namen zu Objekt-oder lokalen code-Namen, die Sie hätten vermeiden können. Singular Tabelle Namen, obwohl Sie vielleicht das Gefühl ein wenig seltsam auf den ersten, bieten erhebliche Vorteile gegenüber pluralisiert Namen und, glaube ich, sind best practice.

InformationsquelleAutor der Antwort dallin

Meine Meinungen über diese sind:

1) Nein, die Tabelle, sollten die Namen der singular.

Während es scheint Sinn zu machen für die einfache Auswahl ( select * from Orders ), es macht weniger Sinn für die OO-äquivalent (Orders x = new Orders).

Einer Tabelle in einer DB ist wirklich der Satz, die Person, macht es mehr Sinn, wenn Sie erst einmal mit set-Logik:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

Letzten Zeile, die eigentliche Logik der Verknüpfung, sieht verwirrend mit plural für Tabellennamen.

Ich bin mir nicht sicher über immer über einen alias (wie Matt schon sagt) löscht.

2) Sie sollten einzigartig, da Sie nur 1 Eigenschaft

3) Niemals, wenn die Spalte name nicht eindeutig ist (wie oben, wo Sie beide haben eine Spalte mit der Bezeichnung [Taste]) der name der Tabelle (oder dessen alias) unterscheiden kann Sie gut genug. Sie wollen Abfragen schnell eingeben und einfach - Präfixe hinzufügen unnötige Komplexität.

4) Was immer du willst, würde ich vorschlagen, CapitalCase

Ich glaube nicht, dass es eine Reihe von absoluten Richtlinien auf diesen.

Solange alles, was Sie wählen ist konsistent über die Anwendung oder DB ich glaube nicht, dass es wirklich wichtig ist.

InformationsquelleAutor der Antwort Keith

1. Auf jeden Fall halten Tabellennamen in der Einzahl, nicht die Menschen
   1. Gleichen hier
   2. Nicht. Ich habe gesehen, einige schreckliche Präfixe, gehen so weit, zu sagen, was zu tun hatten, ist eine Tabelle (tbl_) oder eine Benutzer-Prozedur speichern (usp_). Dies, gefolgt von den Namen der Datenbank... tun Sie es nicht!
   3. Ja. Ich Neige dazu, PascalCase alle meine Tabellennamen

InformationsquelleAutor der Antwort Bell

Namenskonventionen erlauben, die Entwicklungs-team zu entwerfen discovereability und Wartungsfreundlichkeit im Mittelpunkt des Projekts.

Eine gute Namenskonvention braucht Zeit sich zu entwickeln, aber wenn Sie einmal im Ort, es ermöglicht dem team, um vorwärts zu bewegen mit einer gemeinsamen Sprache. Eine gute Namenskonvention wächst organisch mit dem Projekt. Eine gute Namenskonvention leicht zurecht mit den Veränderungen in der längsten und wichtigsten phase des software-Lifecycles - service management in der Produktion.

Hier sind meine Antworten:

1. Ja, Tabellennamen werden sollte, der plural, wenn Sie sich auf eine Reihe von tradesWertpapiereoder Gegenparteien zum Beispiel.
2. Ja.
3. Ja. SQL-Tabellen sind mit dem Präfix tb_, Ansichten Präfix vw_, gespeicherte Prozeduren Präfix usp_-und Trigger-Präfix tg_ gefolgt von den Namen der Datenbank.
4. Spalte name sollte in Kleinbuchstaben angegeben werden, getrennt durch einen Unterstrich.

Benennen ist schwer, aber in jeder organisation gibt es jemanden, der die Dinge zu nennen und in jedem software-team es sollte jemand sein, der die Verantwortung für die Bezeichnungen standards und gewährleistet, dass die Benennung Probleme wie sec_idsec_value und security_id Holen Sie sich frühzeitig geklärt werden bevor Sie sich fest in das Projekt.

Also, was sind die Grundsätze einer guten Namenskonventionen und standards: -

• Verwenden Sie die Sprache Ihrer Kunden und
  Ihre Lösung-domain
• Aussagekräftig sein,
• Einklang
• Eindeutig machen, zu reflektieren und umgestalten
• Keine Abkürzungen verwenden, es sei denn, Sie
  klar sind alle
• Nicht verwenden SQL-Schlüsselwörter als
  Spaltennamen

InformationsquelleAutor der Antwort winsql

Tabellennamen sollten immer in der Einzahl, denn Sie stellen eine Menge von Objekten. Wie Sie sagen, die Herde zu bezeichnen eine Gruppe von Schafen oder Herde tun, bezeichnen eine Gruppe von Vögeln. Keine Notwendigkeit für plural. Wenn ein table-name ist die Zusammensetzung aus zwei Namen und die Namensgebung steht im plural wird es schwer zu wissen, ob der plural-name sollte das erste Wort oder das zweite Wort oder beides.
Es ist die Logik – Objekt.Instanz, nicht Objekte.Instanz. Oder TableName.Spalte TableNames nicht.Spalte(N).
Microsoft SQL ist nicht case sensitive, es ist leichter zu Lesen Tabellennamen, wenn Großbuchstaben verwendet, um separate Tabellen-oder Spaltennamen, wenn Sie aus zwei oder mehr Namen.

InformationsquelleAutor der Antwort Annie

Sehr spät zur party, aber ich wollte noch hinzufügen meine zwei Cent über spaltenpräfixe

Scheint es zwei wichtigsten Argumente für die Verwendung der table_column (oder tableColumn) Benennung standard für Spalten, die beide auf der Grundlage der Tatsache, dass die Spalte name selbst ist einzigartig in der gesamten Datenbank:

1), die Sie nicht haben, um geben Sie den Tabellennamen und/oder Spalten-Aliase in Abfragen die ganze Zeit

2) können Sie ganz einfach durchsuchen Sie Ihr gesamtes code für die Spalte name

Ich denke, beide Argumente sind falsch. Die Lösung für beide Probleme ohne Verwendung von Präfixen ist einfach. Hier mein Vorschlag:

Verwenden Sie immer den Namen der Tabelle in der SQL. E. g., verwenden Sie immer die Tabelle.Spalte anstelle der Spalte.

Es offensichtlich löst 2) wie können Sie jetzt nur die Suche für die Tabelle.Spalte statt table_column.

Aber ich kann hören, wie Sie Schreien, wie Sie zu lösen bedeutet es 1)? Es war genau um dies zu vermeiden. Ja, es war, aber die Lösung war schrecklich entstellt. Warum? Gut, die Präfix-Lösung hinausläuft:

Um zu vermeiden, geben Sie Tabelle.Spalte, wenn es die Zweideutigkeit, die Sie Namen alle Ihre Spalten table_column!

Aber das bedeutet, dass Sie von nun an IMMER haben, schreiben Sie den Namen der Spalte jedes mal, wenn Sie eine Spalte angeben. Aber wenn Sie das tun, egal, was ist der Vorteil gegenüber immer ausdrücklich schreiben Tabelle.Spalte? Genau, es ist kein Vorteil, es ist die exakt gleiche Anzahl an Zeichen zu geben.

edit: ja, ich bin mir bewusst, dass die Benennung der Spalten mit dem Präfix erzwingt die korrekte Verwendung in der Erwägung, dass mein Ansatz stützt sich auf die Programmierer

InformationsquelleAutor der Antwort janb

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

InformationsquelleAutor der Antwort Ian Boyd

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Diese sind die Konventionen, die ich gelehrt wurde, aber Sie sollte sich an alles, was Sie developement Schlauch verwendet.

1. Plural. Es ist eine Sammlung von Entitäten.
2. Ja. Das Attribut ist eine Darstellung der einzigartigen Eigenschaft einer Entität.
3. Ja, URL-Präfix-Tabelle-name ermöglicht leicht nachvollziehbare Benennung der alle Einschränkungen, Indizes und Tabellen-aliases.
4. "Pascal Case" für Tabellen-und Spaltennamen, prefix + ALLE caps für Indizes und Einschränkungen.

InformationsquelleAutor der Antwort Lord Future