it-swarm-eu.dev

Datenbankdesign: Neue Tabelle im Vergleich zu neuen Spalten

(Dies wurde vorgeschlagen, um hier von StackOverflow erneut veröffentlicht zu werden)

Derzeit haben Sie eine Tabelle .. und müssen neue Datenspalten hinzufügen. Nicht jeder Datensatz (auch wenn nach dem Hinzufügen der neuen Datenspalten neue Daten vorliegen) enthält Daten. Ich frage mich also, ob dies für eine neue Tabelle besser geeignet ist, da es sich tatsächlich um eine Erweiterung einiger Datenzeilen handelt und nicht für jede Zeile gilt.

Mit anderen Worten, da es für diese neuen Datenelemente viele nicht verwendete Spalten geben wird, scheint dies für eine neue Tabelle besser geeignet zu sein.

Die erste Tabelle ist eine Aufzeichnung der Seitenaufrufe (derzeit 2 Millionen Datensätze).

 - ID 
 - IP-Adresse 
 - Zeiten angezeigt 
 - Erstellt am Zeitstempel 
 - Datum 

für jede IP-Adresse wird pro Tag ein Datensatz erstellt - und aufeinanderfolgende Seitenaufrufe werden zu den Zeitansichten pro Tag hinzugefügt

zusätzliche Felder wären für die Verfolgung des Ursprungspunkts (dh Google Analytics-Quelle/Medium/Kampagne).

Nicht jeder Besuch wird diese Informationen haben. Ich würde davon ausgehen, dass etwa 10% der Zeilen die Daten enthalten (da diese normalerweise nur beim ersten Besuch zugeordnet werden).

Die Hauptverwendung für die Daten wäre die Zuordnung, woher die Personen kamen. Dies wird möglicherweise häufiger verwendet (was sich dann für die einzelne Tabelle zu eignen scheint).

Schätzen Sie das Feedback - können Sie bei Bedarf weitere hinzufügen

38
cgmckeever

Was Sie ringen, ist vertikale Partitionierung. Dies ist eine physische Datenbankentwurfstechnik zur Verbesserung der Leistung. Wie bei jeder physischen Datenbankentwurfstechnik hängt ihre Anwendbarkeit von den spezifischen Abfragen ab, die Sie optimieren möchten, und davon, ob diese Technik sie optimiert. Wenn diese neuen Felder aus logischer Sicht vom Kandidatenschlüssel für Ihre Entität abhängen, handelt es sich um Fakten, die dazu gehören. Zunächst sollten Sie sicherstellen, dass Sie die funktionale Abhängigkeit dieser neuen Felder von Ihren Kandidatenschlüsseln vollständig verstehen, um zu überprüfen, ob es sich tatsächlich um Fakten zu täglichen Seitenaufrufen handelt. Wenn dies der Fall ist, ist die Entscheidung, sie in eine andere Tabelle zu partitionieren, eine Leistungsoptimierung, die nur durchgeführt werden sollte, wenn Ihre Leistungsziele erreicht werden.

Im Allgemeinen ist die vertikale Partitionierung hilfreich, wenn Sie diese neuen Spalten selten und deutlich von den anderen Spalten in der Originaltabelle abfragen. Indem Sie diese Spalten in einer anderen Tabelle platzieren, die dieselbe PK wie Ihre vorhandene Tabelle hat, können Sie sie direkt abfragen, wenn Sie diese neuen Spalten möchten, und einen viel größeren Durchsatz erzielen, da Sie für diese neue Tabelle viel mehr Zeilen pro Seite auf der Festplatte haben da nicht alle Spalten aus der ursprünglichen Tabelle in diesen Zeilen sitzen. Wenn Sie diese Spalten jedoch immer zusammen mit den Spalten in der Originaltabelle abfragen, ist eine vertikale Partition nicht sehr sinnvoll, da Sie immer eine äußere Verknüpfung benötigen, um sie abzurufen. Seiten aus Tabellen auf der Festplatte werden unabhängig und nie vorab in den Pufferpool eines DBMS aufgenommen, sodass der Join bei jeder Abfrageausführung erfolgen muss, selbst wenn die Daten im Pufferpool fixiert sind. Wenn Sie sie in diesem Szenario zu NULLABLE-Spalten in der Originaltabelle machen, kann die DBMS-Speicher-Engine sie bei NULL effizient speichern und beim Abrufen nicht mehr beitreten.

Es klingt für mich so, als ob Ihr Anwendungsfall der letztere ist und das Hinzufügen von NULLABLE zu Ihrer ursprünglichen Tabelle der richtige Weg ist. Aber wie bei allem anderen im Datenbankdesign kommt es darauf an, und um die richtige Entscheidung zu treffen, müssen Sie Ihre erwartete Arbeitsbelastung kennen und wissen, wovon eine gute Wahl abhängt. Ein gutes Beispiel für einen geeigneten Anwendungsfall für die vertikale Partitionierung ist ein Personensuchfeld, in dem Ihre Anwendung einige sehr selten aufgefüllte Informationen zu einer Person enthält, nach denen jemand suchen möchte, dies aber selten tut. Wenn Sie diese Informationen in eine andere Tabelle einfügen, haben Sie einige gute Optionen für die Leistung. Sie können die Suche so schreiben, dass Sie zwei Abfragen haben - eine, bei der die wichtigsten, immer ausgefüllten Informationen nur für die Suche verwendet werden (z. B. Nachname oder SSN), und eine, bei der die sehr selten ausgefüllten Informationen nur dann äußerlich verknüpft werden, wenn sie zur Suche angefordert werden. Oder Sie können den DBMS-Optimierer nutzen, wenn er intelligent genug ist, um für einen bestimmten Satz von Hostvariablen zu erkennen, dass der äußere Join nicht benötigt wird und ihn nicht ausführt, und Sie daher nur eine Abfrage erstellen müssen.

Welche DBMS-Plattform verwenden Sie? Die Art und Weise, wie die Plattform mit NULL-Spaltenspeicher umgeht, Ihre Abfrage optimiert sowie die Verfügbarkeit von Unterstützung für spärliche Spalten (SQL Server hat dies), wirkt sich auf die Entscheidung aus. Letztendlich würde ich empfehlen, beide Designs in einer Testumgebung mit Daten und Arbeitslast in Produktionsgröße auszuprobieren und zu sehen, welche Ihre Leistungsziele besser erreichen.

29
Todd Everett

Persönlich neige ich dazu, der vorhandenen Tabelle Spalten hinzuzufügen. Der neue Tisch kauft dir eigentlich nichts:

  • sie sparen nicht wirklich viel Platz, da die NULL-Werte in der Originaltabelle keinen Platz beanspruchen und die neue Tabelle eine Art Kennung benötigt, die die Einsparungen ohnehin ausgleicht
  • ihre Abfragen werden komplexer ... where newcolumn is not null wird ein left outer join

In der einzelnen Tabelle bedeutet dies nur, dass Ihre Zeilengröße von Seite zu Seite variieren kann. Dies sollte jedoch nicht viele Ihrer vorhandenen Seiten betreffen, insbesondere wenn sich Ihr Clustered-Index in einer monoton ansteigenden Spalte befindet (Identität oder Datum/Uhrzeit).

10
Aaron Bertrand

Angesichts der von Ihnen bereitgestellten Informationen und der allgemeinen Normalisierung würde ich wahrscheinlich einfach nullfähige Spalten hinzufügen, aber Sie haben nicht genügend Informationen darüber angegeben, wie die Daten verwendet werden, um zu wissen, wie die Daten am besten modelliert werden können ist.

Je nachdem, wie Sie diese Daten tatsächlich verwenden, möchten Sie möglicherweise ein anderes Datenmodell in Betracht ziehen. Wenn Sie diese Daten für die Berichterstellung verwenden, möchten Sie möglicherweise ein Dimensionsmodell untersuchen, das für bestimmte Arten der Berichterstellung effizienter sein kann. Beispielsweise funktioniert die Tageszeitanalyse gut mit einer aufgeteilten Datums- und Zeitdimension.

Bei der Beantwortung von analytischen Fragen wie "Was ist die beliebteste Tageszeit für Besuche aus Kampagnen wie X" oder "An welchem ​​Tag einer Kampagne sehen wir die meisten Besuche pro Stunde" funktioniert eine einzelne Datenzeitspalte nicht Sehr gut (aber dies kann sogar in ein relationales Modell aufgeteilt werden), und es gibt viele Fälle, in denen Sie die IP-Adresse als Dimension behandeln könnten (möglicherweise mit einer Art von Geografiedaten in einer Schneeflocke).

4
Cade Roux