Ist es eine gute Idee, verschiedene Arten von Lookup-Werten in die gleiche Tabelle zu legen?

Question

Auf einem Blog las ich einen Vorschlag viele Tabellen wie folgt zu ersetzen:

lookup_genders 
0 | Unknown 
1 | Female 
2 | Male 

lookup_countries 
0 | Unknown 
1 | Germany 
2 | UK 
3 | USA 

in einer einzigen Tabelle wie folgt aus:

lookups 
0 | Unknown | Gender 
1 | Female | Gender 
2 | Male | Gender 
4 | Germany | Country 
5 | UK  | Country 
6 | USA  | Country 

Der Grund vorausgesetzt, es von vielen fast identischen O zu bekommen war zu befreien/R-Abbildungen.

Ist das eine wirklich gute Idee? Welche Probleme könnten auftreten? Unter welchen Bedingungen wäre das eine gute Idee?

Answer 1

Das erste Mal, wenn Sie Ihren Ländern eine neue Eigenschaft hinzufügen möchten, sind Sie in Schwierigkeiten. Zum Beispiel, was wäre die Hauptstadt von "Female"?

Answer 2

Wir tun dies, wir haben eine GenericOption-Tabelle, die für genau das verwendet wird, was Sie beschreiben. Wir lassen auch 'Super User' neue Optionen zu bestimmten 'Typen' in der Tabelle hinzufügen, um die Wartung zu reduzieren.

Wir verwenden Navision am hinteren Ende, also müssen wir für Tabellen bezahlen!

Answer 3

Ich sehe nicht, warum es eine gute Idee ist, größere Tabellen sind langsamer.

Answer 4

Persönlich bevorzuge ich jede Nachschlagen/Aufzählung in einer separaten Tabelle, aber ich habe Projekte gefunden, die alle Nachschläge in einer einzigen Tabelle haben möchten.

Der Vorteil dieses Ansatzes ist, dass die Wartung (in Bezug auf die UI-Programmierung) mit einer einzigen Tabelle billiger ist, da dies durch Bearbeiten der Basistabelle erreicht werden kann.

Ich empfehle, Ansichten für Land, Geschlecht usw. für App-Logik zu erstellen.

Nachteil: Das Konzept einer generischen Tabelle fällt auseinander, sobald Sie Attribute für Ihre Suchvorgänge speichern möchten. Aber die Ansichten können Ihnen dabei helfen, die Migration zu erleichtern.

Answer 5

Es hängt alles davon ab, was Ihre Konstruktionsziele sind. Ich bin ein Fan von Designs wie dem oben beschriebenen. Sie können problemlos drei Tabellen erstellen: Typen, Entitäten und Eigenschaften und Unterstützung für das Hinzufügen virtuell unbegrenzter Mengen verschiedener Daten verschiedener Typen, die eine schnelle Suche und erweiterbare Modifizierung/Erweiterung unterstützen, oder mit anderen Worten, ein System, das sehr benutzerdefinierbar ist .

Indem Sie eine Eigenschaftentabelle erstellen, in der Sie eine unbegrenzte Anzahl von Eigenschaft-> Wert-Paaren zuweisen können, lösen Sie das Problem Zed ausgelöst.

Answer 6

Es ist im Allgemeinen eine schlechte Idee. Es ist oberflächlich attraktiv, führt aber zu Datenkatastrophen.

Der Hauptgrund dafür ist, dass es schwierig ist, die Fremdschlüsseleinschränkungen zu schreiben, die korrekt auf die One True Lookup Table (OTLT) verweisen. Wenn zum Beispiel jemand den Wert 3 in einer Spalte eingibt, die Geschlecht enthalten soll, kann das DBMS Ihnen nicht helfen, das Problem zu diagnostizieren. Dazu müssten Sie die konstante Zeichenkette 'Gender' in der referenzierenden Tabelle sowie den Wert 3 speichern, und die Fremdschlüsseleinschränkung würde dann sagen, dass es keinen Wert '3, Gender' in der OTLT gibt, also Sie kann die Daten nicht einfügen ". Aber dieser konstante "Gender" -Wert ist ein schrecklicher Fall von wiederholten Werten - viel verschwenderischer als eine separate Tabelle für Gender-Codes.

Answer 7

Vorteile: Sie müssen nicht so viele create-Anweisungen eingeben. Sie müssen nicht mehrere Dateneingabebildschirme erstellen.

Nachteile: Kein Platz, um weitere Attribute eindeutig zu setzen. Es gibt keine eindeutige Möglichkeit, zu validieren, dass an einer beliebigen Stelle auf eine gültige Auswahl aus der Liste verwiesen wird. Die Tabellengröße muss erhöht werden, um den Typcode aufzunehmen. (Und anstatt den Text "Geschlecht" oder "Land" zu setzen, sollten Sie wirklich eine neue Tabelle erstellen, um die Typwerte zu speichern und die ID aus dieser Tabelle zu veröffentlichen.) Versuche, Dropdown-Listen mit Auswahlmöglichkeiten oder anderen ähnlichen Eingabemöglichkeiten zu erstellen um die Komplexität der Überprüfung des Typs hinzuzufügen.

Fazit: Schlechte Idee. Die Vorteile werden leicht auf alternative Weise erreicht. Wie, (a) Lernen Sie, ausschneiden und einfügen. (b) Schreiben Sie einen generischen Dateneingabe-Bildschirm, der mit einem Parameter aufgerufen wird.

Es ist sicherlich wahr, dass es Zeiten gibt, in denen die Normalisierung von Lehrbüchern mehr Probleme verursacht, als sie löst. Dies ist keiner von ihnen.