Wie würden Sie einen sehr breiten "Tisch" implementieren?

Question

Nehmen wir an, Sie modellieren eine Entität mit vielen Attributen (2400+), weit größer als die physische Grenze für eine bestimmte Datenbank-Engine (z. B. ~ 1000 SQL Server). Wenn Sie nichts über die relative Bedeutung dieser Datenpunkte wissen (welche sind am häufigsten/am häufigsten verwendet), abgesehen von den Domänen-/Kandidatenschlüsseln, wie würden Sie sie implementieren?

A) EAV. (boo ... Native relationale Tools aus dem Fenster geworfen.)

B) Gehen Sie geradeaus. Die erste Tabelle hat einen Primärschlüssel und 1000 Spalten bis zum Limit. Die nächste Tabelle ist 1000, Fremdschlüssel für die erste Tabelle. Die letzte Tabelle ist die restlichen 400, auch Fremdschlüssel.

C) Streifen gleichmäßig über ceil(n/limit) Tabellen. Jede Tabelle hat eine gerade Anzahl von Spalten, Fremdschlüssel für die erste Tabelle. 800, 800, 800.

D) Etwas anderes ...

Und warum?

Edit: Dies ist eher eine philosophische/generische Frage, nicht an bestimmte Grenzen oder Motoren gebunden.

Edit^2: Wie viele darauf hingewiesen haben, wurden die Daten wahrscheinlich nicht normalisiert. Zu dieser Zeit machten die geschäftlichen Zwänge eine tiefgehende Forschung unmöglich.

Answer 1

Meine Lösung: weiter untersuchen. Stellen Sie insbesondere fest, ob die Tabelle tatsächlich normalisiert ist (bei 2400 Spalten ist dies höchst unwahrscheinlich).

Wenn nicht, restrukturieren, bis es vollständig normalisiert ist (zu diesem Zeitpunkt sind wahrscheinlich weniger als 1000 Spalten pro Tabelle vorhanden).

Wenn es bereits vollständig normalisiert ist, legen Sie für jedes Attribut (so weit wie möglich) ungefähre Häufigkeiten der Population fest. Platzieren Sie die am häufigsten vorkommenden Attribute in der "home" -Tabelle für die Entität, verwenden Sie 2 oder 3 zusätzliche Tabellen für die weniger häufig verwendeten Attribute. (Versuchen Sie, die Häufigkeit des Auftretens als Kriterium für die Bestimmung der Felder zu verwenden, die in die Tabellen aufgenommen werden sollen.)

Betrachten Sie EAV nur für extrem dünn besetzte Attribute (vorzugsweise gar nicht).

Answer 2

Ohne viel Wissen in diesem Bereich, denke ich, dass eine Entität mit so vielen Attributen wirklich ein Re-Design wirklich braucht. Damit meine ich das große Ding in kleinere Teile zu teilen, die logisch miteinander verbunden sind.

Answer 3

Ich würde die Spalten drehen und sie Reihen machen. Anstatt eine Spalte mit dem Namen des Attributs als Zeichenfolge (nvarchar) zu haben, können Sie sie als fkey in eine Nachschlagetabelle zurückversetzen, die eine Liste aller möglichen Attribute enthält.

es auf diese Weise Rotierende bedeutet, dass Sie:

• haben keine Massen von Tabellen die Details nur ein Element aufnehmen
• haben nicht massiv breite Tabellen
• Sie speichern die Informationen, die Sie aufgrund der Rotation benötigen (wenn Sie kein bestimmtes Attribut speichern möchten, dann haben Sie diese Zeile nicht)

Answer 4

Ich würde eine Eins-zu-viele-Attributtabelle mit einem Fremdschlüssel verwenden zu der Entität.

Eg

Einheiten: id,

attrs: id, ENTITY_ID, attr_name, Wert

ADDED

Oder wie Butler Lampson würde sagen: „alle Probleme in der Informatik gelöst werden können durch eine andere Ebene der Indirektion "

Answer 5

1. Ich würde das Datenmodell viel genauer betrachten . Ist es das 3. normale Formular? Gibt es Gruppen von Attributen , die logisch zusammen in ihre eigenen Tabellen gruppiert werden sollten?

2. Unter der Annahme, es normalisiert wird und die Entität hat wirklich 2400+ Attribute, ich würde nicht so schnell ein EAV model boo. IMHO, es ist die beste, flexibelste Lösung für die Situation, die Sie beschrieben haben. Es bietet Ihnen integrierte Unterstützung für spärliche Daten und eine gute Suchgeschwindigkeit, da die Werte für ein bestimmtes Attribut in einem einzigen Index gefunden werden können.

Answer 6

mir Der Schlüssel Artikel ist dieses Stück:

nichts über die relative Bedeutung dieser Datenpunkte zu kennen (welche sind heiß/am häufigsten verwendet)

Wenn Sie haben eine Idee, welche Felder wichtiger sind, würde ich diese wichtigeren Felder in die "native" Tabelle und lassen Sie eine EAV-Struktur den Rest behandeln.

Die Sache ist, ohne diese Informationen sind Sie wirklich blind blind sowieso. Egal, ob Sie 2400 Felder oder nur 24 Felder haben, Sie sollten eine Vorstellung von der Bedeutung (und damit der relativen Wichtigkeit oder zumindest logischen Gruppierungen) Ihrer Datenpunkte haben.

Answer 7

Verwenden Sie Sparse Columns für bis zu 30000 Spalten. Der große Vorteil gegenüber EAV oder XML ist, dass Sie Filtered Indexes in Verbindung mit Sparse-Spalten verwenden können, um sehr effizient nach gemeinsamen Attributen zu suchen.

Answer 8

Ich möchte die vertikale (Erhöhung der Anzahl der Zeilen) Ansatz anstelle der horizontalen (Erhöhung der Anzahl der Spalten) verwenden.

können Sie versuchen, diesen Ansatz wie

Tabelle - id, property_name - property_value.

Der Vorteil bei der Vorgehensweise ist, dass Sie bei der Einführung der neuen Eigenschaft/Spalte keine Tabelle ändern/erstellen müssen.