Ich starte ein neues Projekt und möchte von Anfang an meine Tabellen- und Spaltennamen erhalten. Zum Beispiel habe ich in Tabellennamen immer Plural verwendet, aber kürzlich gelernt, dass Singular korrekt ist.

Wenn ich also eine Tabelle "user" und dann Produkte habe, die nur der Benutzer haben wird, sollte die Tabelle "user_product" oder nur "product" heißen? Dies ist eine Eins-zu-Viele-Beziehung.

Und weiter, wenn ich (aus irgendeinem Grund) mehrere Produktbeschreibungen für jedes Produkt hätte, wäre es "user_product_description" oder "product_description" oder nur "description"? Natürlich mit den richtigen Fremdschlüsseln. Nur die Beschreibung zu benennen wäre problematisch, da ich auch eine Benutzerbeschreibung oder eine Kontobeschreibung oder was auch immer haben könnte.

Was ist, wenn ich eine reine relationale Tabelle (viele zu viele) mit nur zwei Spalten möchte, wie würde das aussehen? "user_stuff" oder vielleicht so etwas wie "rel_user_stuff"? Und wenn der erste, was würde dies von beispielsweise "user_product" unterscheiden?

Jede Hilfe wird sehr geschätzt und wenn es eine Art Namenskonventionsstandard gibt, den ihr empfiehlt, könnt ihr gerne einen Link erstellen.

Vielen Dank

Tabellenname

kürzlich erlernter Singular ist korrekt

Ja. Hüte dich vor den Heiden. Plural in den Tabellennamen ist ein sicheres Zeichen für jemanden, der keines der Standardmaterialien gelesen hat und keine Kenntnisse der Datenbanktheorie hat.

Einige der wunderbaren Dinge an Standards sind:

• Sie sind alle miteinander integriert
• Sie arbeiten zusammen
• Sie wurden von Köpfen geschrieben, die größer sind als unsere, daher müssen wir sie nicht diskutieren.

Der Standardtabellenname bezieht sich auf jede Zeile in der Tabelle, die in der gesamten Sprache verwendet wird, nicht auf den Gesamtinhalt der Tabelle (wir wissen, dass die CustomerTabelle alle Kunden enthält).

Beziehung, Verbalphrase

In echten relationalen Datenbanken, die modelliert wurden (im Gegensatz zu Datensatzablagesystemen vor den 1970er Jahren [die dadurch gekennzeichnet Record IDssind , dass sie der Einfachheit halber in einem SQL-Datenbankcontainer implementiert sind):

• Die Tabellen sind die Subjekte der Datenbank, daher sind sie wiederum Substantive , Singular
• Die Beziehungen zwischen den Tabellen sind die Aktionen , die zwischen den Substantiven stattfinden. Sie sind also Verben (dh sie sind nicht willkürlich nummeriert oder benannt).
• das ist das Prädikat
• alles, was direkt aus dem Datenmodell gelesen werden kann (siehe meine Beispiele am Ende)
• (Das Prädikat für eine unabhängige Tabelle (das oberste übergeordnete Element in einer Hierarchie) ist, dass es unabhängig ist.)
• Daher wird die Verbalphrase sorgfältig ausgewählt, damit sie am aussagekräftigsten ist, und generische Begriffe werden vermieden (dies wird mit der Erfahrung einfacher). Die Verbalphrase ist während der Modellierung wichtig, da sie bei der Auflösung des Modells hilft, d. H. Klären von Beziehungen, Identifizieren von Fehlern und Korrigieren der Tabellennamen.

Diagramm_A

Natürlich wird die Beziehung in SQL als CONSTRAINT FOREIGN KEYin der untergeordneten Tabelle implementiert (mehr, später). Hier ist die Verbalphrase (im Modell), das Prädikat , das sie darstellt (aus dem Modell zu lesen), und der Name der FK- Einschränkung :

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

Tabelle • Sprache

Verwenden Sie jedoch bei der Beschreibung der Tabelle, insbesondere in technischen Sprachen wie den Prädikaten oder anderen Dokumentationen, Singular und Plural, wie sie natürlich in englischer Sprache vorkommen. Beachten Sie, dass die Tabelle nach der einzelnen Zeile (Relation) benannt ist und die Sprache sich auf jede abgeleitete Zeile (abgeleitete Relation) bezieht:

    Each Customer initiates zero-to-many SalesOrders

nicht

    Customers have zero-to-many SalesOrders 

Wenn ich also eine Tabelle "Benutzer" und dann Produkte habe, die nur der Benutzer haben wird, sollte die Tabelle dann "Benutzerprodukt" oder nur "Produkt" heißen? Dies ist eine Eins-zu-Viele-Beziehung.

(Das ist keine Namenskonventionsfrage; das ist eine Frage zum DB-Design.) Es spielt keine Rolle, ob user::product1 :: n ist. Entscheidend ist, ob productes sich um eine separate Einheit handelt und ob es sich um eine unabhängige Tabelle handelt , d. H. es kann für sich existieren. Deshalb productnicht user_product.

Und wenn productnur im Kontext eines existiert user, dh. es ist eine abhängige Tabelle , daher user_product.

Diagramm_B

Und weiter, wenn ich (aus irgendeinem Grund) mehrere Produktbeschreibungen für jedes Produkt hätte, wäre es "Benutzer-Produkt-Beschreibung" oder "Produkt-Beschreibung" oder nur "Beschreibung"? Natürlich mit den richtigen Fremdschlüsseln. Nur die Beschreibung zu benennen wäre problematisch, da ich auch eine Benutzerbeschreibung oder eine Kontobeschreibung oder was auch immer haben könnte.

Das stimmt. Entweder user_product_descriptionxor product_descriptionist korrekt, basierend auf dem oben Gesagten . Es soll nicht von anderen unterschieden werden xxxx_descriptions, sondern dem Namen ein Gefühl dafür geben, wo er hingehört, wobei das Präfix die übergeordnete Tabelle ist.

Was ist, wenn ich eine reine relationale Tabelle (viele zu viele) mit nur zwei Spalten möchte, wie würde das aussehen? "user-stuff" oder vielleicht so etwas wie "rel-user-stuff"? Und wenn der erste, was würde dies von beispielsweise "Benutzerprodukt" unterscheiden?

1. Hoffentlich sind alle Tabellen in der relationalen Datenbank reine relationale, normalisierte Tabellen. Es ist nicht erforderlich, dies im Namen zu identifizieren (andernfalls werden alle Tabellen angezeigt rel_something).

2. Wenn es nur die PKs der beiden übergeordneten Elemente enthält (wodurch die logische n :: n-Beziehung, die auf logischer Ebene nicht als Entität vorhanden ist, in eine physische Tabelle aufgelöst wird), handelt es sich um eine assoziative Tabelle . Ja, normalerweise ist der Name eine Kombination der beiden übergeordneten Tabellennamen.

   • Beachten Sie, dass in solchen Fällen die Verbalphrase für Eltern von Eltern zu Eltern gilt und als solche gelesen wird, wobei die untergeordnete Tabelle ignoriert wird, da ihr einziger Lebenszweck darin besteht, die beiden Eltern in Beziehung zu setzen.

     Diagramm_C

   • Wenn es sich nicht um eine assoziative Tabelle handelt (dh zusätzlich zu den beiden PKs enthält sie Daten), benennen Sie sie entsprechend, und die Verbalphrasen gelten für sie, nicht für das übergeordnete Element am Ende der Beziehung.

     Diagramm_D

3. Wenn Sie am Ende zwei user_productTabellen haben, ist dies ein sehr lautes Signal, dass Sie die Daten nicht normalisiert haben. Gehen Sie also ein paar Schritte zurück und benennen Sie die Tabellen genau und konsistent. Die Namen lösen sich dann von selbst auf.

Namenskonvention

Jede Hilfe wird sehr geschätzt und wenn es eine Art Namenskonventionsstandard gibt, den ihr empfiehlt, könnt ihr gerne einen Link erstellen.

Was Sie tun, ist sehr wichtig und beeinträchtigt die Benutzerfreundlichkeit und das Verständnis auf allen Ebenen. Es ist also gut, zu Beginn so viel Verständnis wie möglich zu bekommen. Die Relevanz der meisten davon wird nicht klar sein, bis Sie mit dem Codieren in SQL beginnen.

1. Fall ist der erste Punkt, der angesprochen werden muss. Alle Kappen sind nicht akzeptabel. Ein gemischter Fall ist normal, insbesondere wenn die Benutzer direkt auf die Tabellen zugreifen können. Verweisen Sie auf meine Datenmodelle. Beachten Sie, dass ich, wenn der Suchende ein dementes NonSQL verwendet, das nur Kleinbuchstaben enthält, dies gebe. In diesem Fall füge ich Unterstriche hinzu (gemäß Ihren Beispielen).

2. Behalten Sie einen Datenfokus bei , keinen Anwendungs- oder Nutzungsfokus. Es ist immerhin 2011, wir haben Open Architecture seit 1984, und Datenbanken sollen unabhängig von den Apps sein, die sie verwenden.

   Auf diese Weise bleibt die Benennung aussagekräftig und muss nicht korrigiert werden, wenn sie wächst und mehr als die eine App sie verwendet. (Datenbanken, die vollständig in eine einzelne App eingebettet sind, sind keine Datenbanken.) Benennen Sie die Datenelemente nur als Daten.

3. Seien Sie sehr rücksichtsvoll und benennen Sie Tabellen und Spalten sehr genau . Nicht verwenden, UpdatedDatewenn es sich um einen DATETIMEDatentyp handelt UpdatedDtm. Nicht verwenden, _descriptionwenn es eine Dosierung enthält.

4. Es ist wichtig, in der gesamten Datenbank konsistent zu sein . Nicht NumProductan einem Ort verwenden, um die Anzahl der Produkte anzugeben, ItemNooder ItemNuman einem anderen Ort, um die Anzahl der Artikel anzugeben. Wird konsistent NumSomethingfür Nummern und / SomethingNooder SomethingIdBezeichner verwendet.

5. Stellen Sie dem Spaltennamen keinen Tabellennamen oder Funktionscode voran, z user_first_name. SQL stellt den Tabellennamen bereits als Qualifikationsmerkmal bereit:

       table_name.column_name  -- notice the dot
   

6. Ausnahmen:

   • Die erste Ausnahme gilt für PKs. Sie müssen speziell behandelt werden, da Sie sie ständig in Verknüpfungen codieren und möchten, dass sich die Schlüssel von den Datenspalten abheben. Immer benutzen user_id, niemals id.

     • Beachten Sie, dass dies kein Tabellenname ist, der als Präfix verwendet wird, sondern ein korrekter beschreibender Name für die Komponente des Schlüssels: user_idist die Spalte, die einen Benutzer identifiziert, nicht die idder userTabelle.
       • (Außer natürlich in Datensatzablagesystemen, in denen auf die Dateien von Ersatzpersonen zugegriffen wird und keine relationalen Schlüssel vorhanden sind, gibt es ein und dasselbe).
     • Verwenden Sie immer den exakt gleichen Namen für die Schlüsselspalte, wo immer die PK als FK übertragen (migriert) wird.
     • Daher hat die user_productTabelle ein user_idals Bestandteil ihrer PK (user_id, product_no).
     • Die Relevanz wird deutlich, wenn Sie mit dem Codieren beginnen. Erstens ist es bei idvielen Tabellen leicht, sich in die SQL-Codierung zu verwechseln. Zweitens hat jeder andere, dem der ursprüngliche Codierer keine Ahnung hat, was er versucht hat. Beides ist leicht zu verhindern, wenn die Schlüsselspalten wie oben behandelt werden.

   • Die zweite Ausnahme besteht darin, dass mehr als ein FK auf dieselbe übergeordnete Tabellentabelle verweist, die im untergeordneten Element enthalten ist. Gemäß dem Relationale Modell , Verwendung Rollennamen der Bedeutung oder Verwendung, zum Beispiel zu unterscheiden. AssemblyCodeund ComponentCodefür zwei PartCodes. Verwenden Sie in diesem Fall nicht das Undifferenzierte PartCodefür einen von ihnen. Sei präzise.

     Diagramm_E

7. Präfix
   Wenn Sie mehr als 100 Tabellen haben, stellen Sie den Tabellennamen einen Themenbereich voran:

   REF_für Referenztabellen
   OE_für den Auftragserfassungscluster usw.

   Nur auf der physischen Ebene, nicht auf der logischen (es überfrachtet das Modell).

8. Suffix
   Verwenden Sie niemals Suffixe für Tabellen und immer Suffixe für alles andere. Das heißt, bei der logischen, normalen Verwendung der Datenbank gibt es keine Unterstriche. Auf der administrativen Seite werden Unterstriche als Trennzeichen verwendet:

   _VAnsicht ( TableNamenatürlich mit dem Haupt vor)
   _fkFremdschlüssel (der Einschränkungsname, nicht der Spaltenname)
   _cacCache-
   _segSegmenttransaktion
   _tr(gespeicherter Prozess oder Funktion)
   _fnFunktion (nicht transaktional) usw.

   Das Format ist der Tabellen- oder FK-Name, ein Unterstrich und der Aktionsname, ein Unterstrich und schließlich das Suffix.

   Dies ist sehr wichtig, da der Server eine Fehlermeldung ausgibt:

   ____ ____blah blah blah error on object_name

   Sie wissen genau, welches Objekt verletzt wurde und was es zu tun versuchte:

   ____ ____blah blah blah error on Customer_Add_tr

9. Fremdschlüssel (die Einschränkung, nicht die Spalte). Die beste Benennung für eine FK ist die Verwendung der Verbalphrase (abzüglich "jeder" und der Kardinalität).

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

   Verwenden Sie die Parent_Child_fkSequenz, nicht Child_Parent_fkweil (a) sie in der richtigen Sortierreihenfolge angezeigt wird, wenn Sie nach ihnen suchen, und (b) wir immer wissen, um welches Kind es sich handelt, was wir vermuten, ist welches Elternteil. Die Fehlermeldung ist dann erfreulich:

   ____ Foreign key violation on Vendor_Offers_PartVendor_fk.

   Das funktioniert gut für Leute, die sich die Mühe machen, ihre Daten zu modellieren, bei denen die Verbalphrasen identifiziert wurden. Für den Rest, den Rekord Ablagesysteme, usw., Verwendung Parent_Child_fk.

10. Indizes sind etwas Besonderes, daher haben sie eine eigene Namenskonvention, die sich in der Reihenfolge der einzelnen Zeichenpositionen von 1 bis 3 zusammensetzt:

    UEindeutig oder _für nicht eindeutiges
    CClustered oder _für nicht gruppiertes
    _Trennzeichen

    Für den Rest:

    • Wenn der Schlüssel eine oder mehrere Spalten enthält:
      ____ColumnNames

    • Wenn der Schlüssel mehr als ein paar Spalten umfasst:
      ____ PKPrimärschlüssel (gemäß Modell)
      ____ AK[*n*]Alternativer Schlüssel (IDEF1X-Begriff)

    Beachten Sie, dass der Tabellenname im Indexnamen nicht erforderlich ist, da er immer als angezeigt wirdtable_name.index_name.

    Wenn Customer.UC_CustomerIdoder Product.U__AKin einer Fehlermeldung angezeigt wird, werden Ihnen wichtige Informationen angezeigt. Wenn Sie sich die Indizes auf einer Tabelle ansehen, können Sie sie leicht unterscheiden.

11. Finden Sie jemanden, der qualifiziert und professionell ist, und folgen Sie ihm. Schauen Sie sich ihre Designs an und studieren Sie sorgfältig die von ihnen verwendeten Namenskonventionen. Stellen Sie ihnen spezifische Fragen zu allem, was Sie nicht verstehen. Umgekehrt laufen Sie höllisch vor jedem davon, der wenig Rücksicht auf Namenskonventionen oder Standards nimmt. Hier sind einige, um Ihnen den Einstieg zu erleichtern:

    • Sie enthalten echte Beispiele für all das oben Genannte. Stellen Sie Fragen, indem Sie Fragen in diesem Thread umbenennen.
    • Natürlich implementieren die Modelle neben den Namenskonventionen mehrere andere Standards. Sie können diese entweder vorerst ignorieren oder bestimmte neue Fragen stellen .
    • Sie umfassen jeweils mehrere Seiten. Die Inline-Bildunterstützung bei Stack Overflow gilt nur für Vögel und wird in verschiedenen Browsern nicht konsistent geladen. Sie müssen also auf die Links klicken.
    • Beachten Sie, dass PDF-Dateien vollständig navigiert sind. Klicken Sie daher auf die blauen Glastasten oder auf die Objekte, bei denen die Erweiterung identifiziert wird:
    • Leser, die mit dem relationalen Modellierungsstandard nicht vertraut sind, finden die IDEF1X-Notation möglicherweise hilfreich.

Auftragserfassung und Inventar mit standardkonformen Adressen

Einfaches Inter-Office- Bulletin- System für PHP / MyNonSQL

Sensorüberwachung mit voller zeitlicher Fähigkeit

Antworten auf Fragen

^{Das kann im Kommentarbereich nicht vernünftig beantwortet werden.}

Larry Lustig:
... selbst das trivialste Beispiel zeigt ...
Wenn ein Kunde null zu viele Produkte hat und ein Produkt eins zu viele Komponenten hat und eine Komponente eins zu viele Lieferanten hat und ein Lieferant null verkauft -zu viele Komponenten und ein SalesRep hat eins zu viele Kunden. Wie lauten die "natürlichen" Namen der Tabellen, in denen Kunden, Produkte, Komponenten und Lieferanten enthalten sind?

Ihr Kommentar enthält zwei Hauptprobleme:

1. Sie erklären Ihr Beispiel als "das Trivialste", aber es ist alles andere als. Mit dieser Art von Widerspruch bin ich mir nicht sicher, ob Sie es ernst meinen, wenn Sie technisch in der Lage sind.

2. Diese "triviale" Spekulation weist mehrere grobe Normalisierungsfehler (DB Design) auf.

   • Bis Sie diese korrigieren, sind sie unnatürlich und abnormal und ergeben keinen Sinn. Sie können sie auch abnormal_1, abnormal_2 usw. nennen.

   • Sie haben "Lieferanten", die nichts liefern; Zirkelverweise (illegal und unnötig); Kunden, die Produkte ohne kommerzielles Instrument (wie Rechnung oder Verkaufsauftrag) als Grundlage für den Kauf kaufen (oder "besitzen" Kunden Produkte?); ungelöste Viele-zu-Viele-Beziehungen; etc.

   • Sobald dies normalisiert ist und die erforderlichen Tabellen identifiziert sind, werden ihre Namen offensichtlich. Natürlich.

In jedem Fall werde ich versuchen, Ihre Anfrage zu bearbeiten. Das heißt, ich muss etwas Sinn hinzufügen, ohne zu wissen, was Sie gemeint haben. Bitte nehmen Sie Kontakt mit mir auf. Die groben Fehler sind zu viele, um sie aufzulisten, und angesichts der Ersatzspezifikation bin ich nicht sicher, ob ich sie alle korrigiert habe.

• Ich gehe davon aus, dass wenn das Produkt aus Komponenten besteht, das Produkt eine Baugruppe ist und die Komponenten in mehr als einer Baugruppe verwendet werden.

• Da ferner „Supplier Null-to-many - Komponenten verkauft“, dass sie nicht Produkte oder Baugruppen verkaufen, verkaufen sie nur Komponenten.

Spekulation gegen normalisiertes Modell

Falls Sie sich nicht bewusst sind, dass der Unterschied zwischen quadratischen Ecken (unabhängig) und runden Ecken (abhängig) erheblich ist, lesen Sie bitte den Link zur IDEF1X-Notation. Ebenso die durchgezogenen Linien (Identifizieren) gegenüber den gestrichelten Linien (Nicht Identifizieren).

... wie lauten die "natürlichen" Namen der Tabellen mit Kunden, Produkten, Komponenten und Lieferanten?

• Kunde
• Produkt
• Komponente (oder AssemblyComponent für diejenigen, die erkennen, dass eine Tatsache die andere identifiziert)
• Lieferant

Nachdem ich die Tabellen gelöst habe, verstehe ich Ihr Problem nicht. Vielleicht können Sie eine bestimmte Frage stellen.

VoteCoffee:
Wie gehen Sie mit dem Szenario um, das Ronnis in seinem Beispiel gepostet hat, in dem mehrere Beziehungen zwischen zwei Tabellen bestehen (user_likes_product, user_bought_product)? Ich kann falsch verstehen, aber dies scheint zu doppelten Tabellennamen unter Verwendung der von Ihnen beschriebenen Konvention zu führen.

Angenommen, es liegen keine Normalisierungsfehler vor, User likes Producthandelt es sich um ein Prädikat und nicht um eine Tabelle. Verwechsle sie nicht. Lesen Sie meine Antwort, die sich auf Themen, Verben und Prädikate bezieht, und meine Antwort auf Larry unmittelbar darüber.

• Jede Tabelle enthält eine Reihe von Fakten (jede Zeile ist eine Tatsache). Prädikate (oder Sätze) sind keine Fakten, sie können wahr sein oder auch nicht.

  • Das relationale Modell basiert auf der Prädikatenrechnung erster Ordnung (besser bekannt als Logik erster Ordnung). Ein Prädikat ist ein Satz mit einem Satz in einfachem, präzisem Englisch, der als wahr oder falsch bewertet wird.

  • Ferner repräsentiert oder ist jede Tabelle die Implementierung vieler Prädikate, nicht eines.

• Eine Abfrage ist ein Test eines Prädikats (oder einer Reihe von miteinander verketteten Prädikaten), der zu wahr (der Fakt existiert) oder falsch (der Fakt existiert nicht) führt.

• Daher sollten Tabellen, wie in meiner Antwort (Namenskonventionen) beschrieben, für die Zeile, den Fakt und die Prädikate benannt werden (auf jeden Fall ist sie Teil der Datenbankdokumentation), jedoch als separate Liste von Prädikaten .

• Dies ist kein Hinweis darauf, dass sie nicht wichtig sind. Sie sind sehr wichtig, aber das werde ich hier nicht aufschreiben.

• Also schnell. Da das relationale Modell auf FOPC basiert, kann die gesamte Datenbank als eine Reihe von FOPC-Deklarationen, eine Reihe von Prädikaten, bezeichnet werden. (A) Es gibt jedoch viele Arten von Prädikaten, und (b) eine Tabelle repräsentiert nicht ein Prädikat (dies ist die physische Implementierung vieler Prädikate und verschiedener Arten von Prädikaten).

• Daher ist es ein absurdes Konzept, die Tabelle nach "dem" Prädikat, das sie "darstellt" zu benennen.

• Den "Theoretikern" sind nur wenige Prädikate bekannt. Sie verstehen nicht, dass die gesamte Datenbank seit der Gründung des RM auf der Grundlage der FOL aus einer Reihe von Prädikaten und verschiedenen Typen besteht.

  • Und natürlich wählen sie absurde aus den wenigen, die sie kennen : EXISTING_PERSON; PERSON_IS_CALLED. Wenn es nicht so traurig wäre, wäre es lustig.

  • Beachten Sie auch, dass der Standard- oder Atomtabellenname (Benennung der Zeile) für alle Redewendungen (einschließlich aller an die Tabelle angehängten Prädikate) hervorragend funktioniert. Umgekehrt kann der idiotische Name "Tabelle repräsentiert Prädikat" nicht. Das ist in Ordnung für die "Theoretiker", die sehr wenig über Prädikate verstehen, aber ansonsten zurückgeblieben sind.

• Die Prädikate, die für das Datenmodell relevant sind, werden im Modell ausgedrückt und haben zwei Ordnungen.

  1. Unäres Prädikat
     Der erste Satz ist ein Diagramm , kein Text: die Notation selbst . Dazu gehören verschiedene Existenzielle; Constraint-orientiert; und Deskriptor (Attribute) Prädikate.

     • Das bedeutet natürlich, dass nur diejenigen, die ein Standarddatenmodell "lesen" können, diese Prädikate lesen können. Aus diesem Grund können die "Theoretiker", die durch ihre Nur-Text-Denkweise stark verkrüppelt sind, keine Datenmodelle lesen, weshalb sie an ihrer Nur-Text-Denkweise vor 1984 festhalten.

  2. Binäres Prädikat
     Der zweite Satz ist derjenige, der Beziehungen zwischen Fakten bildet. Dies ist die Beziehungslinie. Die Verbalphrase (oben detailliert) identifiziert das Prädikat, den Satz , der implementiert wurde (der per Abfrage getestet werden kann). Expliziter kann man nicht sein.

     • Für jemanden, der Standarddatenmodelle fließend beherrscht , sind daher alle relevanten Prädikate im Modell dokumentiert. Sie benötigen keine separate Liste von Prädikaten (aber die Benutzer, die nicht alles aus dem Datenmodell "lesen" können, tun dies!).

• Hier ist ein Datenmodell , in dem ich die Prädikate aufgelistet habe. Ich habe dieses Beispiel gewählt, weil es die existenziellen usw. Prädikate sowie die Beziehungsprädikate zeigt. Die einzigen Prädikate, die nicht aufgeführt sind, sind die Deskriptoren. Aufgrund des Lernniveaus des Suchenden behandle ich ihn hier als Benutzer.

Daher ist das Ereignis von mehr als einer untergeordneten Tabelle zwischen zwei übergeordneten Tabellen kein Problem. Benennen Sie sie einfach als Existenzfaktor für ihren Inhalt und normalisieren Sie die Namen.

Hier kommen die Regeln ins Spiel, die ich für Verbalphrasen für Beziehungsnamen für assoziative Tabellen angegeben habe. Hier ist eine Diskussion zwischen Prädikat und Tabelle , die alle genannten Punkte zusammenfasst.

Um eine gute kurze Beschreibung der richtigen Verwendung von Prädikaten und ihrer Verwendung zu erhalten (was ein ganz anderer Kontext ist als der, auf Kommentare hier zu antworten), besuchen Sie diese Antwort und scrollen Sie nach unten zum Abschnitt Prädikate .

Charles Burns:
Mit Sequenz meinte ich das Objekt im Oracle-Stil, das nur zum Speichern einer Zahl und des nächsten nach einer Regel verwendet wird (z. B. "1 hinzufügen"). Da Oracle keine automatischen ID-Tabellen hat, werden normalerweise eindeutige IDs für Tabellen-PKs generiert. INSERT INTO foo (id, somedata) VALUES (foo_s.nextval, "data" ...)

Ok, das nennen wir eine Key- oder NextKey-Tabelle. Nennen Sie es als solches. Wenn Sie über SubjectAreas verfügen, geben Sie mit COM_NextKey an, dass dies in der gesamten Datenbank üblich ist.

Übrigens ist das eine sehr schlechte Methode zum Generieren von Schlüsseln. Überhaupt nicht skalierbar, aber mit der Leistung von Oracle ist es wahrscheinlich "in Ordnung". Außerdem zeigt dies an, dass Ihre Datenbank voller Ersatzzeichen ist, die in diesen Bereichen nicht relational sind. Dies bedeutet extrem schlechte Leistung und mangelnde Integrität.

Singular vs. Plural: Wählen Sie eine aus und bleiben Sie dabei.

Spalten sollten nicht mit einem Präfix / Suffix / Infix versehen oder in irgendeiner Weise mit Verweisen auf die Tatsache fixiert werden, dass es sich um eine Spalte handelt. Gleiches gilt für Tische. Nennen Sie die Tabellen nicht EMPLOYEE_T oder TBL_EMPLOYEES, da die Dinge in der Sekunde, in der sie durch eine Ansicht ersetzt werden, sehr verwirrend werden.

Betten Sie keine Typinformationen in Namen ein, z. B. "vc_firstname" für varchar oder "flavour_enum". Betten Sie auch keine Einschränkungen in Spaltennamen wie "department_fk" oder "employee_pk" ein.

Eigentlich ist das einzig gute an * Fixes ich denken kann, ist , dass Sie reservierte Wörter wie verwenden können where_t, tbl_order, user_vw. Natürlich hätte in diesen Beispielen die Verwendung von Plural das Problem gelöst :)

Nennen Sie nicht alle Schlüssel "ID". Schlüssel, die sich auf dasselbe beziehen, sollten in allen Tabellen denselben Namen haben. Die Benutzer-ID-Spalte kann in der Benutzertabelle und allen Tabellen, die auf den Benutzer verweisen, als USER_ID bezeichnet werden. Die Umbenennung erfolgt nur, wenn verschiedene Benutzer unterschiedliche Rollen spielen, z. B. Nachricht (sender_user_id, recept_user_id). Dies ist sehr hilfreich bei größeren Abfragen.

In Bezug auf CaSe:

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

Im Allgemeinen ist es besser, "Zuordnungstabellen" so zu benennen, dass sie mit der beschriebenen Beziehung übereinstimmen, als mit den Namen der Tabellen, auf die verwiesen wird. Ein Benutzer kann eine beliebige Anzahl von Beziehungen zu den Produkten hat: user_likes_product, user_bought_product, user_wants_to_buy_product.

Es gibt kein "Richtiges" zwischen Singular und Plural - es ist meistens Geschmackssache.

Es hängt zum Teil von Ihrem Fokus ab. Wenn Sie sich die Tabelle als Einheit vorstellen, enthält sie 'Pluralformen' (weil sie viele Zeilen enthält - daher ist ein Pluralname angemessen). Wenn Sie sich vorstellen, dass der Tabellenname eine Zeile in einer Tabelle identifiziert, bevorzugen Sie "Singular". Dies bedeutet, dass Ihre SQL an einer Zeile aus der Tabelle arbeitet. Das ist in Ordnung, obwohl es normalerweise eine übermäßige Vereinfachung ist. SQL funktioniert mit Mengen (mehr oder weniger). Wir können jedoch mit Singular die Antworten auf diese Frage finden.

1. Da Sie wahrscheinlich eine Tabelle 'user', ein anderes 'product' und die dritte Tabelle benötigen, um Benutzer mit Produkten zu verbinden, benötigen Sie eine Tabelle 'user_product'.

2. Da die Beschreibung für ein Produkt gilt, würden Sie 'product_description' verwenden. Es sei denn, jeder Benutzer benennt jedes Produkt für sich ...

3. Die Tabelle 'user_product' ist (oder könnte) ein Beispiel für eine Tabelle mit einer Produkt-ID und einer Benutzer-ID und sonst nicht viel. Sie benennen die Tabellen mit zwei Attributen auf dieselbe allgemeine Weise: 'user_stuff'. Dekorative Präfixe wie 'rel_' helfen nicht wirklich. Sie werden zum Beispiel einige Leute sehen, die 't_' vor jedem Tabellennamen verwenden. Das ist keine große Hilfe.

Pluralformen sind nicht schlecht, solange sie konsequent verwendet werden - aber Singular ist meine Präferenz.

Ich würde auf Unterstriche verzichten, es sei denn, Sie möchten eine Viele-zu-Viele-Beziehung skizzieren. und verwenden Sie ein Anfangskapital, da es dabei hilft, Dinge in ORMs zu unterscheiden.

Es gibt jedoch viele Namenskonventionen. Wenn Sie also Unterstriche verwenden möchten, ist dies in Ordnung, solange dies konsistent erfolgt.

So:

User

UserProduct (it is a users products after all)

Wenn nur ein Benutzer ein Produkt haben kann, dann

UserProductDescription

Aber wenn das Produkt von Benutzern geteilt wird:

ProductDescription

Wenn Sie Ihre Unterstriche für viele-zu-viele-Beziehungen speichern, können Sie Folgendes tun:

UserProduct_Stuff

ein M-zu-M zwischen UserProduct und Stuff zu bilden - nicht sicher aus der Frage die genaue Natur der vielen-zu-vielen erforderlich.

Es ist nicht korrekter, Singular als Plural zu verwenden. Wo haben Sie das gehört? Ich würde eher sagen, dass die Pluralform häufiger für die Benennung von Datenbanktabellen verwendet wird ... und meiner Meinung nach auch logischer. Die Tabelle enthält meistens mehr als eine Zeile;) In einem konzeptionellen Modell sind die Namen der Entitäten jedoch häufig singulär.

Zu Ihrer Frage, wenn 'Produkt' und 'Produktbeschreibung' Konzepte mit einer Identität (dh Entitäten) in Ihrem Modell sind, würde ich einfach die Tabellen 'Produkte' und 'Produktbeschreibungen' nennen. Für Tabellen, die zum Implementieren einer Viele-zu-Viele-Beziehung verwendet werden, verwende ich am häufigsten die Namenskonvention "SideA2SideB", zum Beispiel "Student2Course".