it-swarm.com.de

Umgang mit dem Tabellendesign mit variablen Spalten

Ich habe ein Tabellenentwurfsszenario und möchte als Nicht-DBA-Typ Meinungen, die skalierbarer sind.

Angenommen, Sie werden gebeten, Informationen zu Häusern für ein U-Bahn-Gebiet aufzuzeichnen, beginnend mit einer kleinen Nachbarschaft (200 Häuser), die aber schließlich auf über 5000000 Häuser anwächst.

Sie müssen Basisinformationen speichern: ID # (Eine eindeutige Chargennummer, die wir als eindeutigen Index verwenden können), Adresse, Stadt, Bundesland, Postleitzahl. Feiner, einfacher Tisch wird damit umgehen.

Aber jedes Jahr werden Sie gebeten, zusätzliche Informationen über alle Häuser aufzuzeichnen - und welche Informationen werden sich jedes Jahr ändern. So werden Sie beispielsweise im ersten Jahr gebeten, den Nachnamen und die Quadratmeterzahl des Eigentümers aufzuzeichnen. Im zweiten Jahr werden Sie aufgefordert, den Nachnamen beizubehalten, aber die Fläche zu löschen und stattdessen die Vornamen der Eigentümer zu sammeln.

Schließlich ändert sich jedes Jahr die Anzahl der zusätzlichen Spalten. Könnte mit 2 zusätzlichen Spalten beginnen, dann nächstes Jahr zu 6 gehen und dann wieder zu 2 zurückkehren.

Ein Tabellenansatz besteht also darin, zu versuchen, die benutzerdefinierten Informationen als Spalten in den Haustabellen hinzuzufügen, sodass nur eine Tabelle vorhanden ist.

Aber ich habe eine Situation, in der jemand die Tische dafür wie folgt ausgelegt hat:

Spalten "Haustabelle": ID, Adresse, Stadt, Bundesland, Postleitzahl - mit einer Zeile pro Haus

ID   Addr              City     State  Zip 
-------------------------------------------
1    10 Maple Street   Boston      MA  11203

2    144 South Street  Chelmsford  MA  11304

3    1 Main Avenue     Lowell      MA  11280

Spalten "Benutzerdefinierte Infotabelle": ID, Name, Wert - wobei die Tabelle wie folgt aussieht:

ID   Name             Value

1    Last Name        Smith

2    Last Name        Harrison

3    Last Name        Markey

1    Square Footage   1200

2    Square Footage   1930

3    Square Footage 

Es gibt also mehrere Zeilen für jeden einzelnen Hausdatensatz. Jedes Jahr, wenn sich die erforderlichen optionalen Informationen ändern, wird diese Tabelle buchstäblich neu erstellt, sodass sie im nächsten Jahr wie folgt aussehen könnte:

1    Last Name    Smith

2    Last Name    Harrison

3    Last Name    Markey

1    First Name   John

2    First Name   Harry

3    First Name   Jim

Schließlich sammeln Sie 100.000 Hausreihen UND ein Jahr gibt es 10 zusätzliche Informationen; Die zweite Tabelle enthält jetzt 1.000.000 Informationszeilen, von denen viele redundante (Beschreibungs-) Informationen enthalten. Die Datenbankanforderungen insgesamt bestehen darin, dass die Benutzer die Hauszeileninformationen + die zugehörigen benutzerdefinierten Feldwerte tausende Male pro Tag abrufen müssen.

Also meine Frage: Wäre es schlecht (oder schrecklich), stattdessen entweder:

A) Legen Sie die Haustabelle mit einer Schätzung der maximalen Anzahl benutzerdefinierter Spalten (möglicherweise "1" bis "10" genannt) an und fügen Sie diese benutzerdefinierten Werte direkt in die Hauszeilen ein

OR

B) Speichern Sie die benutzerdefinierten Informationen in der Haustabelle. Erstellen Sie jedoch jedes Jahr, wenn sich die Anforderungen ändern, die Haustabelle mit nur der Anzahl der Spalten neu, die für benutzerdefinierte Informationen erforderlich sind, mit der Idee, dass die Anforderungen verrückt werden könnten und Sie nie wissen, wie viele maximal sind Möglicherweise werden optionale Felder angefordert.

Danke, hoffe das macht Sinn!

17
Schmitty23

Sie haben so ziemlich 4 Möglichkeiten:

NoSQL - Definition Jeder Datensatz wird als Satz von Schlüssel/Wert-Paaren gespeichert. Es ist sehr flexibel und schnell. Nicht alle Berichtersteller unterstützen diese Art der Speicherung. Es gibt viele Beispieldatenbankimplementierungen von NoSQL. Die derzeit beliebteste ist MongoDB.

[~ # ~] eav [~ # ~] - Definition Hier drehen Sie entweder den gesamten Tisch oder einen Teil (in einem anderen Tisch) auf die Seite. Dies ist eine gute Wahl, wenn Sie bereits über eine interne relationale Datenbank verfügen, von der Sie sich nicht einfach entfernen können. Das von Ihnen angegebene Beispiel für eine benutzerdefinierte Infotabelle ist ein gutes Beispiel für eine EAV-Tabelle.

Standardtabellen mit XML-Spalten - Stellen Sie sich vor, NoSQL trifft auf relationale Tabellen. Die in einer XML-Spalte gespeicherten Daten können jedes von XML unterstützte Format haben, einschließlich mehrerer korrelierter Unterdaten. Für die Spalten, von denen Sie wissen, dass sie "normale" Spalten sind, können sie als geeigneter Spaltentyp zum Speichern der Daten (Nachname, Adresse, Stadt, Bundesland usw.) erstellt werden.

Standardtabellen mit vielen zusätzlichen Spalten - Sie haben eine relationale Datenbank und können weder XML noch EAV verwenden und NoSQL ist keine Option. Fügen Sie viele zusätzliche Spalten für jeden Typ hinzu. Ich würde 30 oder mehr Varchar, 30 oder mehr Ganzzahlen, 15 oder mehr Zahlen erraten. Und wenn Sie eine Spalte für einen Wert verwenden, verwenden Sie sie nicht mehr . Und löschen Sie auch nicht die Spalte .

Von all diesen Lösungen bin ich der Meinung, dass Sie entweder den NoSQL- oder den EAV-Ansatz am erfolgreichsten finden, wenn Sie Ihren Code und Ihr Schema am wenigsten umgestalten.

Sie werden eine Situation haben, in der Sie Daten in einem Jahr und nicht im nächsten Jahr erfassen und anschließend erneut erfassen. Der Versuch, die älteren Daten mit den richtigen Informationen zu aktualisieren, ist problematisch und teuer. Lagerung ist weder.

15
Adam Zuckerman

Um Ihre Frage zu diesen beiden Optionen zu beantworten, scheint mir keine richtig zu sein. A) wird dich einsperren und B) ist eine Menge Arbeit. Das aktuelle Schema, das Sie beschreiben, ist nicht schlecht (außer dass der Informationsname ("Vorname", "Quadratfuß" usw.) als Zeichenfolge anstelle einer ID verwendet wird, die auf eine Nachschlagetabelle verweist.

Dies scheint mir jedoch ein guter Kandidat für eine NoSQL-Datenbank zu sein ( http://en.wikipedia.org/wiki/NoSQL ). Obwohl ich nie mit einer solchen Datenbank gearbeitet habe, ist das, was Sie beschreiben, ein typisches Szenario, das dadurch gelöst wird.

2
ETL

Können Sie alle Szenarien aufzählen, für die Sie diese Daten speichern möchten?

wenn es eine endliche Anzahl von Spaltenkombinationen gibt, die auf die Tabelle angewendet werden können, versuchen Sie, eine "Basistabelle" mit gemeinsamen Spalten zu modellieren, die für alle Szenarien gelten, und erstellen Sie dann weitere Tabellen (um eine Art Vererbung zu implementieren). Dies wird im ERD- und Datenbankdesign als Subtyp/Supertyp bezeichnet.)

eine Tabelle für jedes Szenario. Auf diese Weise halten Sie zumindest die Tabellen sauber und können vermeiden, dass die Adresse in der Spalte "Nachname" gespeichert wird.

schauen Sie sich diese Entwurfsfrage an: https://stackoverflow.com/questions/554522/something-like-inheritance-in-database-design

0
joe

Wenn die gleichzeitige Anzahl von benutzerdefinierten Spalten endlich ist und die Grenzwerte bekannt sind (z. B. nicht mehr als 10-20 benutzerdefinierte Spalten für Zeichenfolgen, nicht mehr als x Spalten für Ganzzahlen usw.)
Sie können die Basistabelle mit zusätzlichen Feldern pro Datentyp verwenden und anstatt die Tabelle jedes Jahr neu zu erstellen, eine Ansicht für dieses Jahr erstellen, die nur die relevanten benutzerdefinierten Spalten enthält, und die generischen Felder umbenennen, um den Inhalt für dieses Jahr wiederzugeben.

House Table:
ID, Addr, City, State, Zip, custom_string1,cs_2,cs_3,custom_integer_1,ci_2,ci_3 ...

create view house_2014 as 
select ID, Addr, City, State, Zip,
custom_string1 as last_name,cs_2 as first_name ...

Das Problem bei diesem Ansatz ist, dass Sie keinen Verlauf haben, aber leicht jedes Jahr eine Kopie erstellen können, bevor Sie die Spaltenanforderungen ändern.

create table house_2014_archive as select * from house_2014;
drop house_2014;
create view house_2015 as "select column list for new year";
0
scheelec