Frage Tabellennamensdilemma: Singular vs. Plural Namen [geschlossen]


Die Academia sagt, dass Tabellennamen die Singularität der Entität sein sollten, in der sie Attribute speichern.

Ich mag keine T-SQL, die eckige Klammern um Namen benötigt, aber ich habe a umbenannt Users Tabelle für den Singular, für immer verurteilen diejenigen, die den Tisch verwenden, um manchmal Brackets zu verwenden.

Mein Bauchgefühl ist, dass es richtiger ist, mit der Einzahl zu bleiben, aber mein Bauchgefühl ist auch, dass Klammern unerwünschte Namen wie Spaltennamen mit Leerzeichen in ihnen usw. anzeigen.

Soll ich bleiben oder gehen?


1171


Ursprung


Antworten:


Andere haben ziemlich gute Antworten gegeben, was "Standards" betrifft, aber ich wollte nur hinzufügen ... Ist es möglich, dass "Benutzer" (oder "Benutzer") nicht wirklich eine vollständige Beschreibung der Daten in der Tabelle ist ? Nicht, dass Sie mit Tabellennamen und Spezifität verrückt werden sollten, aber vielleicht wäre etwas wie "Widget_Users" (wo "Widget" der Name Ihrer Anwendung oder Website ist) geeigneter.


206



Ich hatte dieselbe Frage, und nachdem ich alle Antworten hier gelesen habe, bleibe ich definitiv bei SINGULAR, Gründe:

Grund 1 (Konzept). Sie können sich eine Tasche mit Äpfeln wie "AppleBag" vorstellen, es spielt keine Rolle, ob sie 0, 1 oder eine Million Äpfel enthält, es ist immer dieselbe Tasche. Tabellen sind nur das, Container, der Tabellenname muss beschreiben, was er enthält, nicht wie viele Daten er enthält. Darüber hinaus geht es beim pluralen Konzept eher um eine gesprochene Sprache (eigentlich um festzustellen, ob es eine oder mehrere gibt).

Grund 2. (Bequemlichkeit). es ist leichter, singuläre Namen als plural hervorzubringen. Objekte können einen unregelmäßigen Plural oder nicht Plural haben, aber sie werden immer einen Singular haben (mit wenigen Ausnahmen wie News).

  • Kunde
  • Auftrag
  • Benutzer
  • Status
  • Nachrichten

Grund 3. (Ästhetik und Ordnung). Speziell in Master-Detail-Szenarien liest sich das besser, richtet sich besser nach Namen aus und hat eine logischere Reihenfolge (Master zuerst, Detail Sekunde):

  • 1. bestellen
  • 2.OrderDetail

Verglichen mit:

  • 1.OrderDetails
  • 2 Bestellungen

Grund 4 (Einfachheit). Alles zusammen, Tabellennamen, Primärschlüssel, Beziehungen, Entity-Klassen ... ist besser, nur einen Namen (Singular) statt zwei zu kennen (Singular-Klasse, Plural-Tabelle, Singular-Feld, Singular-Plural Master-Detail .. .)

  • Customer
  • Customer.CustomerID
  • CustomerAddress
  • public Class Customer {...}
  • SELECT FROM Customer WHERE CustomerID = 100

Sobald Sie wissen, dass Sie mit "Kunde" zu tun haben, können Sie sicher sein, dass Sie dasselbe Wort für alle Datenbankinteraktionsanforderungen verwenden.

Grund 5. (Globalisierung). Die Welt wird kleiner, vielleicht haben Sie ein Team aus verschiedenen Nationalitäten, nicht jeder hat Englisch als Muttersprache. Für einen nicht-englischen Sprachprogrammierer wäre es einfacher, sich "Repository" als "Repositories" oder "Status" anstelle von "Status" vorzustellen. Einzelne Namen zu verwenden, kann zu weniger Fehlern durch Tippfehler führen, Zeit sparen, weil Sie nicht denken müssen "ist es Kind oder Kinder?", Und somit die Produktivität verbessern.

Grund 6. (Warum nicht?). Es kann Ihnen sogar Zeit sparen, Speicherplatz sparen und sogar Ihre Computertastatur länger halten!

  • SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
  • SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

Du hast 3 Buchstaben, 3 Bytes, 3 zusätzliche Tastaturtreffer gespeichert :)

Und schließlich können Sie diejenigen nennen, die mit reservierten Namen herumspielen wie:

  • Benutzer> LoginUser, AppUser, SystemUser, CMSUser, ...

Oder nutze die berüchtigten eckigen Klammern [Benutzer]


1385



Wenn Sie Object Relational Mapping-Tools verwenden oder in der Zukunft vorschlagen Singular.

Einige Tools wie LLBLGen können automatisch mehrere Namen wie Benutzer zu Benutzer korrigieren, ohne den Tabellennamen selbst zu ändern. Warum ist das wichtig? Denn wenn es zugeordnet ist, soll es wie User.Name anstelle von Users.Name aussehen oder schlechter von einigen meiner alten Datenbanken sein, die tblUsers.strName benennen, was nur im Code verwirrend ist.

Meine neue Faustregel ist zu beurteilen, wie es aussehen wird, sobald es in ein Objekt umgewandelt wurde.

Eine Tabelle, die ich gefunden habe, passt nicht zu der neuen Benennung, die ich benutze, ist UsersInRoles. Aber es wird immer diese paar Ausnahmen geben und auch in diesem Fall sieht es gut aus als UsersInRoles.Username.


242



Ich bevorzuge die nicht abgelenkt Nomen, das im Englischen Singular ist.

Die Angabe der Nummer des Tabellennamens führt zu orthographischen Problemen (wie viele der anderen Antworten zeigen), aber dies zu tun, weil Tabellen normalerweise mehrere Zeilen enthalten, ist ebenfalls semantisch voller Lücken. Dies ist offensichtlicher, wenn wir eine Sprache betrachten, die Substantive auf der Basis von Groß- und Kleinschreibung beeinflusst (wie es die meisten tun):

Da wir normalerweise etwas mit den Zeilen machen, warum sollte man den Namen nicht in den Akkusativ bringen? Wenn wir einen Tisch haben, an den wir mehr schreiben als wir lesen, warum nicht den Namen in Dativ setzen? Es ist ein Tisch von etwas, warum nicht den Genitiv benutzen? Wir würden dies nicht tun, da die Tabelle als ein abstrakter Container definiert ist, der unabhängig von seinem Status oder seiner Verwendung existiert. Das Substantiv ohne einen präzisen und absoluten semantischen Grund zu plappern, ist plappernd.

Die Verwendung des nicht-abgeleiteten Substantivs ist einfach, logisch, regulär und sprachunabhängig.


174



Welche Konvention verlangt, dass Tabellen singuläre Namen haben? Ich dachte immer, es wären Pluralnamen.

Ein Benutzer wird der Tabelle Benutzer hinzugefügt.

Diese Seite stimmt zu:
http://vyaskn.tripod.com/object_naming.htm#Tables

Diese Seite stimmt dem nicht zu (aber ich stimme nicht zu):
http://justinsomnia.org/writings/naming_conventions.html


Wie andere schon erwähnt haben: Das sind nur Richtlinien. Wählen Sie eine Konvention, die für Sie und Ihr Unternehmen / Projekt funktioniert und bleiben Sie dabei. Das Umschalten zwischen Singular und Plural oder manchmal Abkürzungen und manchmal nicht, ist viel ärgerlicher.


115



Wie wäre es damit als ein einfaches Beispiel:

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

gegen

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

Das SQL in letzterem ist fremder als das erstere.

Ich stimme für Singular.


55



Ich bin der festen Überzeugung, dass in einem Entity Relation Diagram die Entity mit einem singulären Namen reflektiert werden sollte, ähnlich einem Klassennamen, der singulär ist. Einmal instanziiert, spiegelt der Name seine Instanz wider. Bei Datenbanken ist die Entität, wenn sie in eine Tabelle (eine Sammlung von Entitäten oder Datensätzen) umgewandelt wird, Plural. Entität, Benutzer wird zur Tabelle Benutzer gemacht. Ich würde mit anderen zustimmen, die vorgeschlagen haben, dass der Name Benutzer möglicherweise zu Employee oder etwas, das für Ihr Szenario anwendbar ist, verbessert werden könnte.

Dies macht dann mehr Sinn in einer SQL-Anweisung, weil Sie aus einer Gruppe von Datensätzen auswählen und wenn der Tabellenname singulär ist, liest es nicht gut.


53