Tabellennamensdilemma: Singular vs. Plural Names [geschlossen]

Laut Academia sollten Tabellennamen der Singular der Entität sein, in der sie Attribute speichern.

Ich mag kein T-SQL, das eckige Klammern um Namen erfordert, aber ich habe eine UsersTabelle in Singular umbenannt und diejenigen, die die Tabelle verwenden, für immer verurteilt, manchmal Klammern verwenden zu müssen.

Mein Bauchgefühl ist, dass es korrekter ist, beim Singular zu bleiben, aber mein Bauchgefühl ist auch, dass Klammern unerwünschte Zeichen wie Spaltennamen mit Leerzeichen usw. anzeigen.

Soll ich bleiben oder gehen?

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

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

Grund 1 (Konzept). Sie können sich eine Tüte mit Äpfeln wie "AppleBag" vorstellen. Es spielt keine Rolle, ob sie 0, 1 oder eine Million Äpfel enthält. Es ist immer dieselbe Tüte. Tabellen sind nur das, Container, der Tabellenname muss beschreiben, was er enthält, nicht wie viele Daten er enthält. Darüber hinaus handelt das Plural-Konzept eher von einer gesprochenen Sprache (tatsächlich, um festzustellen, ob es eine oder mehrere gibt).

Grund 2 . (Bequemlichkeit). Es ist einfacher, mit singulären Namen herauszukommen, als mit mehreren. Objekte können unregelmäßige Pluralformen oder gar keinen Plural haben, haben aber immer einen Singular (mit wenigen Ausnahmen wie Nachrichten).

• Kunde
• Auftrag
• Benutzer
• Status
• Nachrichten

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

• 1.Bestellung
• 2.OrderDetail

Verglichen mit:

• 1.OrderDetails
• 2 Bestellungen

Grund 4 (Einfachheit). Alles zusammen, Tabellennamen, Primärschlüssel, Beziehungen, Entitätsklassen ... ist es besser, nur einen Namen (Singular) anstelle von zwei (Singularklasse, Plural-Tabelle, Singular-Feld, Singular-Plural-Master-Detail) zu kennen. .)

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

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

Grund 5 . (Globalisierung). Die Welt wird immer kleiner, vielleicht haben Sie ein Team verschiedener Nationalitäten, nicht jeder hat Englisch als Muttersprache. Für einen nicht-muttersprachlichen Programmierer in englischer Sprache wäre es einfacher, an "Repository" als an "Repositories" oder "Status" anstelle von "Status" zu denken. Singuläre Namen können zu weniger Fehlern führen, die durch Tippfehler verursacht werden. Sparen Sie Zeit, indem Sie nicht denken müssen, ob es sich um ein Kind oder Kinder handelt, und verbessern Sie so die Produktivität.

Grund 6 . (Warum nicht?). Sie können sogar Schreibzeit sparen, Speicherplatz sparen und sogar die Lebensdauer Ihrer Computertastatur verlängern!

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

Sie haben 3 Buchstaben, 3 Bytes, 3 zusätzliche Tastaturtreffer gespeichert :)

Und schließlich können Sie diejenigen benennen, die mit reservierten Namen durcheinander kommen, wie:

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

Oder benutze die berüchtigten eckigen Klammern [Benutzer]

Wenn Sie Tools für die objektrelationale Zuordnung verwenden oder dies in Zukunft tun werden, empfehle ich Singular .

Einige Tools wie LLBLGen können mehrere Namen wie Benutzer zu Benutzer automatisch 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 oder noch schlimmer aus einigen meiner alten Datenbanktabellen mit dem Namen tblUsers.strName aussehen, was im Code nur verwirrend ist.

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

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

Ich bevorzuge die nicht reflektierte Substantivs, das auf Englisch singulär ist.

Das Beugen der Nummer des Tabellennamens führt zu orthografischen Problemen (wie viele der anderen Antworten zeigen), aber dies zu wählen, da Tabellen normalerweise mehrere Zeilen enthalten, ist auch semantisch voller Löcher. Dies ist offensichtlicher, wenn wir eine Sprache betrachten, die Substantive nach Groß- und Kleinschreibung beugt (wie die meisten):

Da wir normalerweise etwas mit den Zeilen machen, warum nicht den Namen in den Akkusativ setzen? Wenn wir eine Tabelle haben, in die wir mehr schreiben als lesen, warum nicht den Namen in einen Dativ setzen? Es ist eine Tabelle von etwas, warum nicht den Genitiv verwenden? Wir würden dies nicht tun, da die Tabelle als abstrakter Container definiert ist, der unabhängig von seinem Status oder seiner Verwendung existiert. Das Substantiv ohne einen genauen und absoluten semantischen Grund zu beugen, plappert.

Die Verwendung des nicht reflektierten Substantivs ist einfach, logisch, regelmäßig und sprachunabhängig.

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

Ein Benutzer wird zur Benutzertabelle hinzugefügt.

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

Diese Seite ist anderer Meinung (aber ich bin damit nicht einverstanden):
http://justinsomnia.org/writings/naming_conventions.html

Wie andere bereits erwähnt haben: Dies 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ürzende Wörter und manchmal nicht ist viel erschwerender.

Wie wäre es damit als einfaches Beispiel:

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

vs.

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

Das SQL in letzterem klingt seltsamer als das erstere.

Ich stimme für Singular .

Ich bin der festen Überzeugung, dass in einem Entitätsbeziehungsdiagramm die Entität 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 anderen zustimmen, die vorgeschlagen haben, den Namen Benutzer möglicherweise auf Mitarbeiter zu verbessern oder etwas, das für Ihr Szenario besser geeignet ist.

Dies ist dann in einer SQL-Anweisung sinnvoller, da Sie aus einer Gruppe von Datensätzen auswählen und der Tabellenname singulär ist und nicht gut gelesen werden kann.

Ich bleibe bei Singular für Tabellennamen und jede Programmiereinheit.

Der Grund? Die Tatsache, dass es auf Englisch unregelmäßige Pluralformen wie Mäuse, Mäuse und Schafe, Schafe gibt . Wenn ich dann eine Sammlung brauche , benutze ich einfach Mäuse oder Schafe und gehe weiter.

Es hilft wirklich, die Pluralität hervorzuheben, und ich kann leicht und programmatisch bestimmen, wie die Sammlung von Dingen aussehen würde.

Meine Regel lautet also: Alles ist einzigartig, jede Sammlung von Dingen ist einzigartig, an die ein s angehängt ist. Hilft auch bei ORMs.

IMHO sollten Tabellennamen wie Kunden Plural sein .

Klassennamen sollten wie Customer singulär sein, wenn sie einer Zeile in der Customers- Tabelle zugeordnet sind.

Singular. Ich kaufe kein Argument, das am logischsten ist - jeder hält seine eigene Präferenz für am logischsten. Egal was Sie tun, es ist ein Chaos, wählen Sie einfach eine Konvention und halten Sie sich daran. Wir versuchen, eine Sprache mit sehr unregelmäßiger Grammatik und Semantik (normale gesprochene und geschriebene Sprache) einer sehr regulären (SQL) Grammatik mit sehr spezifischer Semantik zuzuordnen.

Mein Hauptargument ist, dass ich die Tabellen nicht als Menge, sondern als Beziehungen betrachte.

Die AppUserBeziehung sagt also, welche Entitäten sind AppUsers.

Die AppUserGroupBeziehung sagt mir, welche Entitäten sindAppUserGroups

Die AppUser_AppUserGroupBeziehung sagt mir, wie die AppUsersund AppUserGroupszusammenhängen.

Das AppUserGroup_AppUserGroup Beziehung sagt mir, wie AppUserGroupsundAppUserGroups verwandt sind (dh Gruppenmitglieder von Gruppen).

Mit anderen Worten, wenn ich über Entitäten nachdenke und wie sie zusammenhängen, denke ich an Beziehungen im Singular, aber wenn ich an Entitäten in Sammlungen oder Mengen denke, sind die Sammlungen oder Mengen natürlich Plural.

In meinem Code und im Datenbankschema verwende ich Singular. In Textbeschreibungen verwende ich zur besseren Lesbarkeit den Plural - dann verwende ich Schriftarten usw., um den Tabellen- / Beziehungsnamen vom Plural zu unterscheiden.

Ich betrachte es gerne als chaotisch, aber systematisch - und auf diese Weise gibt es immer einen systematisch generierten Namen für die Beziehung, die ich ausdrücken möchte, was für mich sehr wichtig ist.

Ich würde mich auch für Pluralformen entscheiden , und mit dem oben genannten Benutzerdilemma verfolgen wir den Ansatz der eckigen Klammerung.

Wir tun dies, um eine Einheitlichkeit zwischen Datenbankarchitektur und Anwendungsarchitektur zu gewährleisten, mit dem zugrunde liegenden Verständnis, dass die Users- Tabelle eine Sammlung von Benutzerwerten ist , ebenso wie eine Users- Sammlung in einem Code-Artefakt eine Sammlung von User ist Objekten ist.

Wenn unser Datenteam und unsere Entwickler dieselbe konzeptionelle Sprache sprechen (obwohl nicht immer dieselben Objektnamen), ist es einfacher, Ideen zwischen ihnen zu vermitteln.

Ich persönlich bevorzuge es, mehrere Namen zu verwenden, um eine Menge darzustellen. Für meinen relationalen Verstand "klingt" das einfach besser.

Genau in diesem Moment verwende ich einzelne Namen, um ein Datenmodell für mein Unternehmen zu definieren, da sich die meisten Mitarbeiter bei der Arbeit damit wohler fühlen. Manchmal muss man einfach jedem das Leben leichter machen, anstatt seine persönlichen Vorlieben durchzusetzen. (So ​​bin ich in diesem Thread gelandet, um eine Bestätigung zu erhalten, was die "Best Practice" für die Benennung von Tabellen sein sollte.)

Nachdem ich alle Argumente in diesem Thread gelesen hatte, kam ich zu einer Schlussfolgerung:

Ich mag meine Pfannkuchen mit Honig, egal was jedermanns Lieblingsgeschmack ist. Aber wenn ich für andere Leute koche, werde ich versuchen, ihnen etwas zu servieren, das sie mögen.

Singular. Ich würde ein Array mit einer Reihe von Benutzerzeilendarstellungsobjekten "Benutzer" nennen, aber die Tabelle ist "die Benutzertabelle". Die Tabelle als nichts anderes als die Menge der darin enthaltenen Zeilen zu betrachten, ist falsch, IMO; Die Tabelle besteht aus den Metadaten, und der Satz von Zeilen ist hierarchisch an die Tabelle angehängt. Es handelt sich nicht um die Tabelle selbst.

Ich benutze natürlich die ganze Zeit ORMs und es hilft, dass ORM-Code, der mit mehreren Tabellennamen geschrieben wurde, dumm aussieht.

Ich habe eigentlich immer gedacht, dass es eine beliebte Konvention ist, mehrere Tabellennamen zu verwenden. Bis zu diesem Punkt habe ich immer Plural verwendet.

Ich kann das Argument für einzelne Tabellennamen verstehen, aber für mich ist Plural sinnvoller. Ein Tabellenname beschreibt normalerweise, was die Tabelle enthält. In einer normalisierten Datenbank enthält jede Tabelle bestimmte Datensätze. Jede Zeile ist eine Entität und die Tabelle enthält viele Entitäten. Also die Pluralform für den Tabellennamen.

Eine Tabelle mit Autos hätte den Namen Autos und jede Reihe ist ein Auto. Ich gebe zu, dass table.fieldes die beste Vorgehensweise ist , die Tabelle zusammen mit dem Feld so anzugeben , dass singuläre Tabellennamen besser lesbar sind. In den folgenden beiden Beispielen ist das erstere jedoch sinnvoller:

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

Ehrlich gesagt werde ich meine Position in dieser Angelegenheit überdenken und mich auf die tatsächlichen Konventionen verlassen, die von der Organisation verwendet werden, für die ich entwickle. Ich denke jedoch, dass ich mich für meine persönlichen Konventionen an mehrere Tabellennamen halten werde. Für mich macht es mehr Sinn.

Ich mag keine Plural-Tabellennamen, weil einige Substantive im Englischen nicht zählbar sind (Wasser, Suppe, Bargeld) oder sich die Bedeutung ändert, wenn Sie sie zählbar machen (Huhn gegen Huhn; Fleisch gegen Vogel). Ich mag es auch nicht, Abkürzungen für Tabellennamen oder Spaltennamen zu verwenden, da dies der bereits steilen Lernkurve eine zusätzliche Steigung hinzufügt.

Ironischerweise könnte ich Usereine Ausnahme machen und sie Userswegen USER (Transac-SQL) aufrufen , weil ich es auch nicht mag, Klammern um Tabellen zu verwenden, wenn ich nicht muss.

Ich benenne auch gerne alle ID-Spalten als Id, nicht ChickenIdoder ChickensId(was machen Plural-Leute dagegen?).

All dies liegt daran, dass ich die Datenbanksysteme nicht richtig respektiere. Ich wende nur das One-Trick-Pony-Wissen aus OO-Namenskonventionen wie Java aus Gewohnheit und Faulheit an. Ich wünschte, es gäbe eine bessere IDE-Unterstützung für kompliziertes SQL.

Wir verwenden ähnliche Standards, wenn wir bei der Skripterstellung [] um Namen und gegebenenfalls Schemaqualifizierer fordern - in erster Linie werden Ihre Wetten durch die SQL-Syntax gegen zukünftige Namensübernahmen abgesichert.

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

Dies hat unsere Seelen in der Vergangenheit gerettet - einige unserer Datenbanksysteme haben mehr als 10 Jahre von SQL 6.0 bis SQL 2005 gearbeitet - weit über ihre beabsichtigte Lebensdauer hinaus.

Tabellen: Plural

In der Benutzertabelle sind mehrere Benutzer aufgeführt.

Modelle: Singular

Ein einzelner Benutzer kann aus der Benutzertabelle ausgewählt werden.

Controller: Plural

http://myapp.com/users würde mehrere Benutzer auflisten.

Das ist sowieso meine Einstellung dazu.

Ich bin ein Fan von singulären Tabellennamen, da sie meine ER-Diagramme mit CASE-Syntax leichter lesbar machen, aber wenn ich diese Antworten lese, habe ich das Gefühl, dass sie sich nie sehr gut durchgesetzt haben? Ich persönlich liebe es. Es gibt eine gute Übersicht mit Beispielen dafür, wie lesbar Ihre Modelle sein können, wenn Sie einzelne Tabellennamen verwenden, Ihren Beziehungen Aktionsverben hinzufügen und für jede Beziehung gute Sätze bilden. Es ist alles ein bisschen übertrieben für eine Datenbank mit 20 Tabellen, aber wenn Sie eine Datenbank mit Hunderten von Tabellen und einem komplexen Design haben, wie werden Ihre Entwickler sie jemals ohne ein gut lesbares Diagramm verstehen?

http://www.aisintl.com/case/method.html

Was das Präfixieren von Tabellen und Ansichten betrifft, hasse ich diese Praxis absolut. Geben Sie einer Person überhaupt keine Informationen, bevor Sie ihnen möglicherweise schlechte Informationen geben. Jeder, der eine Datenbank nach Objekten durchsucht, kann eine Tabelle ganz einfach von einer Ansicht unterscheiden. Wenn ich jedoch eine Tabelle mit dem Namen tblUsers habe, entscheide ich mich aus irgendeinem Grund, sie in Zukunft in zwei Tabellen umzustrukturieren, um sie so zu vereinheitlichen, dass kein alter Code beschädigt wird Ich habe jetzt eine Ansicht namens tblUsers. An diesem Punkt bleiben mir zwei unattraktive Optionen, eine Ansicht mit einem tbl-Präfix, die einige Entwickler verwirren kann, oder das Umschreiben einer anderen Ebene, entweder der mittleren Ebene oder der Anwendung, um auf meine neue Struktur oder den Namen viewUsers zu verweisen. Das negiert meiner Meinung nach einen großen Teil des Wertes von Ansichten.

Das System tables/viewsdes Servers selbst ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, etc.) ist fast immer im Plural. Ich denke, aus Gründen der Konsistenz würde ich ihrem Beispiel folgen.

Wenn wir uns Systemtabellen ansehen MS SQL Server's, sind ihre von Microsoft zugewiesenen Namen in plural.

Die Systemtabellen von Oracle sind in benannt singular. Obwohl einige von ihnen Plural sind. Oracle empfiehlt Plural für benutzerdefinierte Tabellennamen. Das macht nicht viel Sinn, dass sie eine Sache empfehlen und einer anderen folgen. Dass die Architekten dieser beiden Software-Giganten ihre Tabellen nach unterschiedlichen Konventionen benannt haben, macht auch wenig Sinn ... Was sind diese Leute ... Doktoranden?

Ich erinnere mich an die Wissenschaft, die Empfehlung war einzigartig.

Zum Beispiel, wenn wir sagen:

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

vielleicht wird b / c jeweils IDaus einer bestimmten Zeile ausgewählt ...?

Dies mag etwas überflüssig sein, aber ich würde vorschlagen, vorsichtig zu sein. Nicht unbedingt, dass es schlecht ist, Tabellen umzubenennen, aber Standardisierung ist genau das; ein Standard - diese Datenbank ist möglicherweise bereits "standardisiert", jedoch schlecht :) - Ich würde Konsistenz als besseres Ziel vorschlagen, da diese Datenbank bereits vorhanden ist und vermutlich aus mehr als nur 2 Tabellen besteht.

Wenn Sie nicht die gesamte Datenbank standardisieren können oder zumindest planen, auf dieses Ziel hinzuarbeiten, vermute ich, dass Tabellennamen nur die Spitze des Eisbergs sind und sich möglicherweise auf die jeweilige Aufgabe konzentrieren, um den Schmerz schlecht benannter Objekte zu ertragen Ihr bestes Interesse -

Praktische Konsistenz ist manchmal der beste Standard ... :)

my2cents ---

Mögliche Alternativen:

• Benennen Sie die Tabelle SystemUser um
• Verwenden Sie Klammern
• Behalten Sie die Plural-Tabellennamen bei.

IMO mit Klammern ist technisch der sicherste Ansatz, wenn auch etwas umständlich. IMO ist es 6 von einem, ein halbes Dutzend von dem anderen, und Ihre Lösung läuft wirklich nur auf persönliche / Team-Vorlieben hinaus.

Mein Ansatz ist die Semantik, je nachdem, wie Sie Ihren Container definieren. Zum Beispiel eine "Tüte Äpfel" oder einfach "Äpfel" oder eine "Apfeltüte" oder "Apfel".

Beispiel: Eine "College" -Tabelle kann 0 oder mehr Colleges enthalten. Eine Tabelle von "Colleges" kann 0 oder mehr Colleges enthalten

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

Mein Fazit ist, dass entweder in Ordnung ist, aber Sie müssen definieren, wie Sie (oder die Personen, die damit interagieren) vorgehen, wenn Sie sich auf die Tabellen beziehen. "Axttabelle" oder eine "Tabelle von xs"

Wie andere hier erwähnt haben, sollten Konventionen ein Werkzeug sein, um die Benutzerfreundlichkeit und Lesbarkeit zu verbessern. Nicht als Fessel oder Verein, um Entwickler zu foltern.

Meine persönliche Präferenz ist es jedoch, singuläre Namen sowohl für Tabellen als auch für Spalten zu verwenden. Dies kommt wahrscheinlich von meinem Programmierhintergrund. Klassennamen sind im Allgemeinen singulär, es sei denn, es handelt sich um eine Art Sammlung. In meinen Gedanken speichere oder lese ich einzelne Datensätze in der fraglichen Tabelle, daher macht Singular für mich Sinn.

Diese Vorgehensweise ermöglicht es mir auch, mehrere Tabellennamen für diejenigen zu reservieren, in denen viele-zu-viele-Beziehungen zwischen meinen Objekten gespeichert sind.

Ich versuche, reservierte Wörter in meinen Tabellen- und Spaltennamen zu vermeiden. In dem hier fraglichen Fall ist es sinnvoller, gegen die singuläre Konvention für Benutzer zu verstoßen, um zu vermeiden, dass eine Tabelle gekapselt werden muss, die das reservierte Wort des Benutzers verwendet.

Ich mag es, Präfixe in begrenzter Weise zu verwenden (tbl für Tabellennamen, sp_ für Proc-Namen usw.), obwohl viele glauben, dass dies Unordnung hinzufügt. Ich bevorzuge auch CamelBack-Namen gegenüber Unterstrichen, da ich beim Eingeben des Namens immer das + anstelle von _ drücke. Viele andere sind anderer Meinung.

Hier ist ein weiterer guter Link für Richtlinien für Namenskonventionen: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

Denken Sie daran, dass der wichtigste Faktor in Ihrer Konvention darin besteht, dass es für die Personen, die mit der betreffenden Datenbank interagieren, sinnvoll ist. Es gibt keinen "Einen Ring, um sie alle zu regieren", wenn es um Namenskonventionen geht.

Ich denke, die Verwendung des Singulars wurde uns an der Universität beigebracht. Gleichzeitig könnte man jedoch argumentieren, dass eine Tabelle im Gegensatz zur objektorientierten Programmierung keine Instanz ihrer Datensätze ist.

Ich glaube, ich tippe im Moment wegen mehrerer Unregelmäßigkeiten im Englischen zugunsten des Singulars. Auf Deutsch ist es sogar noch schlimmer, weil es keine konsistenten Pluralformen gibt - manchmal kann man nicht sagen, ob ein Wort Plural ist oder nicht, ohne den spezifizierenden Artikel davor (der / die / das). Und in chinesischen Sprachen gibt es sowieso keine Pluralformen.

Ich habe einmal "Dude" für die Benutzertabelle verwendet - dieselbe kurze Anzahl von Zeichen, kein Konflikt mit Schlüsselwörtern, immer noch ein Verweis auf einen generischen Menschen. Wenn ich mir keine Sorgen um die stickigen Köpfe gemacht hätte, die den Code sehen könnten, hätte ich das so gehalten.

Ich habe immer Singular verwendet, nur weil mir das beigebracht wurde. Als ich kürzlich zum ersten Mal seit langer Zeit ein neues Schema erstellt habe, habe ich mich aktiv dafür entschieden, diese Konvention beizubehalten, einfach weil ... sie kürzer ist. Das Hinzufügen eines 's' am Ende jedes Tabellennamens erscheint mir ebenso nutzlos wie das Hinzufügen von 'tbl_' vor jedem.

Ich dachte immer, das sei eine blöde Konvention. Ich benutze mehrere Tabellennamen.

(Ich glaube, der Grund für diese Richtlinie ist, dass sie ORM-Codegeneratoren das Erstellen von Objekt- und Sammlungsklassen erleichtert, da es einfacher ist, einen Pluralnamen aus einem Singularnamen zu erstellen als umgekehrt.)

Ich verwende nur Substantive für meine Tabellennamen, die gleich geschrieben sind, ob Singular oder Plural:

Elch Fisch Hirsch Flugzeug Sie Hosen Shorts Brille Schere Spezies Nachkommen

Ich habe dies in keiner der vorherigen Antworten klar zum Ausdruck gebracht. Viele Programmierer haben beim Arbeiten mit Tabellen keine formale Definition im Sinn. Wir kommunizieren oft intuitiv in Form von "Datensätzen" oder "Zeilen". Mit einigen Ausnahmen für denormalisierte Beziehungen werden Tabellen normalerweise so entworfen, dass die Beziehung zwischen den Nichtschlüsselattributen und dem Schlüssel eine festgelegte theoretische Funktion darstellt.

Eine Funktion kann als Teilmenge eines Kreuzprodukts zwischen zwei Mengen definiert werden, wobei jedes Element der Tastenmenge höchstens einmal in der Zuordnung vorkommt. Daher ist die aus dieser Perspektive resultierende Terminologie eher singulär. Man sieht die gleiche singuläre (oder zumindest nicht plurale) Konvention in anderen mathematischen und rechnerischen Theorien, die Funktionen beinhalten (z. B. Algebra- und Lambda-Kalkül).