Frage

In einer Datenbank Prototyp habe ich eine Reihe von Feldern (wie Name, Beschreibung, Status), die in mehreren, funktionell verschiedenen Tabellen erforderlich ist.

Diese Felder haben immer die gleiche End-User-Funktionalität für die Kennzeichnung, Anzeige, Suche, Filterung usw. Sie sind nicht von einem Fremdschlüssel Teil. Wie soll das modelliert werden?

kann ich denke an den folgenden Varianten:

  • Jede Tabelle alle bekommt diese Attribute. In diesem Fall, wie würden Sie sie nennen? Das gleiche, in jeder Tabelle oder mit einem Tabellennamen Präfix (wie usrname, prodName)

  • Bewegen Sie sie in eine Tabelle Attribute, einen Fremdschlüssel zu den "Kern" Tabellen hinzufügen, Referenzierung Attributes.PK

  • Wie oben, aber statt einem Fremdschlüssel, die Attributes.PK als PK in der jeweiligen Kerntabelle als auch verwendet werden.

War es hilfreich?

Lösung

es klingt wie Sie die Idee der Normalisierung ein bisschen zu weit sein könnte. denken Sie daran, es ist die Idee, dass Sie reduzieren Redundanz in der Daten . Ihr Beispiel scheint über „Redundanz“ in den Meta-Informationen Ihres Datenbank-Designs Sie sich Sorgen um anzuzeigen.

letztlich aber user.name und user.description sind Funktionalität unterscheidet sich von product.name und product.description, und sollten als solche behandelt werden. für status, hängt es, was Sie damit meinen. status ist nur ein Indikator für ein Produkt / eine Benutzer-Datensatz aktiv zu sein oder nicht? wenn ja, dann könnte es Sinn machen, dass an einen anderen Tisch zu teilen.

mit den Informationen, die Sie zur Verfügung gestellt, wenn „aktiv / abgelaufen / gelöscht“ ist lediglich ein Hinweis auf Staat innerhalb der Datenbank, dann würde ich auf jeden Fall mit einer Tabellenstruktur vereinbarer wie folgt:

users            products         status
  id               id               id
  name             name             name
  description      description
  status_id        status_id

jedoch, wenn status denkbar geändert werden könnte etwas semantisch anders (dh für die Nutzer darstellen, vielleicht „aktiv / Ruhestand / gefeuert“, ich Aufspaltung würde vorschlagen, dass bis das Design zukunftssicher:

user_status     product_status
  id              id
  name            name

kurz gesagt, normalisiert die Daten, nicht Ihr Datenbank-Design.

Andere Tipps

Wenn Sie nicht die gleichen Namen oder die Beschreibung Werte verwenden in Tabellen sollten Sie nicht, dass die Daten normalisieren. Statustypen sind in der Regel wiederverwendet werden, so, normalisieren diejenigen. Zum Beispiel:

order_status_types
- id
- name
- description

shipping_accounts
- id
- name
- description

orders
- order_status_type_id
- shipping_account_id

preferences
- shipping_account_id

Normalisierungs ist oft am besten Praxis in jeder relationalen Datenbank (innerhalb Grund).

Wenn Sie Felder wie Zustand (den Zustand innerhalb eines Landes Sinn), dann eine Referenztabelle wie „Staat“ mit (id, short_name, long_name etc ...) könnte der Weg zu gehen, dann wird jeder Datensatz, der Referenzen nur ein Zustand braucht eine state_id Spalte, die, wie Sie erwähnt haben, ein Verweis auf einen Eintrag in der Zustandstabelle ist.

Doch in einigen Fällen Normalisierung aller Daten ist nicht unbedingt erforderlich, da es nur die Dinge kompliziert, aber es sollte klar sein, wo es zu tun ist und wo es nicht zu tun.

Hope, das hilft.

Ich würde jedem Tisch seinen eigenen Satz von Spalten geben, auch wenn sie die gleichen Namen haben und sind logisch ähnlich.

Wenn Sie jemals eine der Tabellen ändern müssen durch Hinzufügen oder einige dieser Spalten löschen oder dessen Datentyp ändern, dann können Sie es nur in der Tabelle, wo es gehört, statt herauszufinden, wie Ihre gemeinsamen erschweren -Attribut Tabelle.

jede Tabelle die Kontrolle über seine eigenen Attribute Geben fördert Kohäsions , was eine gute Sache ist. Es vermeidet auch Sie Ihre Frage in welche Richtung die Fremdschlüssel gehen.

Wie bei Spalte Namensgebung, ist es nicht notwendig oder ratsam Präfixe auf Spaltennamen zu setzen. Wenn Sie jemals eine trete, dass die Ergebnisse in den Spalten des gleichen Namens aus zwei Tabellen kommen, verwenden Sie Aliase, sie zu unterscheiden.

Ich habe immer jede Tabelle einen 3-Buchstaben-Code angegeben, die ich dann in allen Feldnamen verwenden. Auf diese Weise in der Produkttabelle I prdname, prddescription, prdstatus haben, und in der Lieferantendatei Ich habe venname, vendescription, venstatus. Wenn die Dinge verbunden zu bekommen, gibt es keine Notwendigkeit, über gleichnamige Felder zu kümmern.

Natürlich sind die Tische haben alle ein Feld namens plain old id und die Produkttabelle ein Feld namens Venid würde, die in der Kreditorentabelle auf das ID-Feld bezieht. In diesem Fall stelle den prd Präfix ich es nicht, weil Venid durchaus Sinn macht und ist nonambiguous.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top