Dynamische Erstellung von neuen Lookup-Tabellen basierend auf Werten in Hauptdatentabelle

Question

ich auf eine Anwendung arbeite, die alle hochgeladenen CSV-Daten akzeptiert, speichert sie zusammen mit anderen Datensätzen, die zuvor hochgeladen wurden, und dann erzeugt eine Ausgabe (CSV oder HTML) auf der Grundlage der Benutzer auswählen, welche Spalten / Werte, die sie zurückgegeben werden sollen. Die Datenbank wird automatisch erweitert neue / andere Spalten und Datentypen zu handhaben, wie erforderlich. Dies ist in dem Vorzug ein Entity-Attribut-Wert-Modell.

Beispiel - diese 2 Sätze auf eine leere Datenbank hochgeladen werden:

Daten-Set A:

name  | dept  | age   
------+-------+------
Bob   | Sales | 24
Tim   | IT    | 32

Daten-Set B:

name  | dept  | age  | salary
------+-------+------+--------
Bob   | Sales | 24   | £20,000
Tim   | IT    | 32   | £20,000

Wird programmatisch der Tabelle ‚Daten‘ ändern, so dass die Ergebnisse Dataset A in 3 neu erstellten Spalten (Name, Abteilung, Alter) zu importieren. Importieren von Daten-Set B Ergebnisse in 1 neu geschaffener Spalte (Gehalt). Im Moment vergisst darüber, ob die Cord-Sets sollen oder nicht kombiniert werden und dass es keine Normalisierung.

Das Problem, das ich habe, ist, dass einige Spalten auch Lookup-Werte haben wird - sagen wir, dass die Abteilung Spalte in der Zukunft irgendwann Werte zugeordnet, die die Adresse und Telefonnummern dieser Abteilung geben. Das gleiche könnte für die Gehaltsspalte wahr sein, aufzublicken Steuer Gruppierungen etc.

Die Anzahl der Spalten in diesem großen Tisch soll nicht zu hoch wird (einige hundert) aber hoch genug sein, um den Benutzer zu wollen, die Lookup-Tabelle Struktur und Werte über einen Admin-Panel zu verwalten, anstatt haben die Entwickler jedes Mal einzubeziehen .

Die Frage ist, ob für jede Spalte (Wert, Beschreibung) einzelne Lookup-Tabellen zu verwenden, oder eine kombinierte Lookup-Tabelle, die die Spalte verweist (Spalt Wert, Beschreibung). Normalerweise würde ich für einzelne Lookup-Tabellen entscheiden, aber hier ist die Anwendung müssen sie automatisch erstellen (z lookup_dept, lookup_salary) und dann ein neues in die Master-SQL-Anweisung kommen hinzu. Dies würde auf Antrag des Benutzers durchgeführt wird und nicht, wenn die Spalte hinzugefügt (um Hunderte von leeren Tabellen zu vermeiden).

Die kombinierte Lookup-Tabelle auf der anderen Seite müssten mehrere Male auf die Datentabelle verbunden werden, auf dem Spaltennamen der Auswahl jedes Mal.

Individuelle Lookups scheint mir sinnvoll zu machen, aber ich kann völlig auf dem Holzweg werden.

Answer 1

Ich würde zustimmen, dass einzelne Tabellen vorzuziehen. Es ist besser skalierbar und besser für die Abfrageoptimierung. wenn in Zukunft auch die Benutzer auf einem bestimmten Lookup mehr Spalten wollen, dann können Sie sie hinzufügen.

Ja, wird die Anwendung über Tabellen und Constraints automatisch erstellen: Ich würde dies normalerweise nicht tun, aber dann wird diese Anwendung bereits vorhandene Tabellen zu verändern und das Hinzufügen von Spalten zu ihnen, das würde ich nicht normalerweise entweder tun

Answer 2

Ach, die " Eine wahre Lookup-Tabelle " Idee. Eines der seltenen Male, die ich mit Herrn Celko zustimmen. Google-Suche zu

Einzeltische jedes Mal. Es heißt „korrigieren“ in der Datenbank Sinne.

Mein Grund (keine Normalisierung Pedanten bitte): Jede Zeile in einer Tabelle speichert eine Einheit nur. zB Obst Namen, Automarken, Telefon Marken. Mischen sie ist Unsinn. Ich könnte eine Handy-Marke namens „Apple“ haben. Er ... warten Sie eine Minute ...

Answer 3

Du hast gesagt,

  

Dies ist bevorzugt zu einem Entity-Attribut-Wert-Modell.

Aber es scheint mir, wie das ist genau das, was Sie brauchen.

Betrachten wir ein RDF triplestore Verwendung und Abfrage mit SPARQL.

Vergessen SQL, das ein Job für RDF ist.