Bedenken Sie, dass wir einen großen Satz statistischer Daten für einen Datensatz haben. zB 20-30 INTSpalten. Ist es besser, den gesamten Satz in einer Tabelle zu belassen, da alle zu einem Datensatz gehören, ODER eine andere Tabelle zu erstellen, die mit einer Eins-zu-Eins-Beziehung verbunden ist?
Ersteres hat den Vorteil JOIN, dass alle statistischen Daten für den entsprechenden Datensatz vermieden werden und ein schneller Zugriff darauf möglich ist.
Letzteres hat den Vorteil, dass die Säule sauber bleibt. Die erste Spalte ist leseintensiv und die zweite schreibintensiv. Natürlich denke ich, dass dies keinen signifikanten Einfluss auf die Leistung hat, da ich InnoDB mit Blockierung auf Zeilenebene verwende.
Im Allgemeinen möchte ich wissen, ob es praktisch sinnvoll ist, verschiedene Datensätze für einen einzelnen Datensatz zu trennen.
Antworten:
Wenn es in die Regeln der Normalisierung passt, können 1: 1-Beziehungen (per Definition!) Normalisiert werden. Mit anderen Worten, es gibt nichts an 1: 1-Beziehungen, was es ihnen unmöglich macht, den normalen Formen zu gehorchen.
Um Ihre Frage nach der Praktikabilität von 1: 1-Beziehungen zu beantworten, ist dies manchmal ein äußerst nützliches Konstrukt, z. B. wenn Sie Subtypen mit unterschiedlichen Prädikaten (Spalten) haben.
Die Gründe, warum Sie 1: 1-Beziehungen verwenden würden, hängen von Ihrer Sichtweise ab. DBAs neigen dazu, alles als Leistungsentscheidung zu betrachten. Datenmodellierer und Programmierer neigen dazu, diese Entscheidungen als design- oder modellorientiert zu betrachten. Tatsächlich gibt es viele Überschneidungen zwischen diesen Gesichtspunkten. Es hängt davon ab, welche Perspektiven und Prioritäten Sie haben. Hier einige Beispiele für Motivationen für 1: 1-Beziehungen:
Sie haben eine Teilmenge von Spalten, die sehr breit sind, und Sie möchten sie aus Leistungsgründen physisch in Ihrem Speicher trennen.
Sie haben eine Teilmenge von Spalten, die nicht häufig gelesen oder aktualisiert werden, und Sie möchten sie aus Leistungsgründen von den häufig verwendeten Spalten fernhalten.
Sie haben einige Spalten, die im Allgemeinen optional sind, aber sie sind obligatorisch, wenn Sie wissen, dass der Datensatz von einem bestimmten Typ ist.
Sie haben einige Spalten, die für einen Subtyp logisch zusammengehören, und Sie möchten sie so modellieren, dass sie gut zum Objektmodell Ihres Codes passen.
Sie haben einige Spalten, die nur für einige Subtypen eines Entitätstyps gelten können, und Sie möchten, dass Ihr Schema das Fehlen dieser Daten für andere Subtypen erzwingt.
Sie haben einige Spalten, die zu einer Entität gehören, aber Sie müssen diese bestimmten Spalten mithilfe restriktiverer Zugriffsregeln (z. B. Gehalt für eine Mitarbeitertabelle) schützen.
Sie sehen also, manchmal ist der Treiber Leistung, manchmal ist es Modellreinheit oder nur der Wunsch, deklarative Schema-Regeln voll auszunutzen.
quelle
You have some subset of columns that are very wide and you want to segregate them physically in your storage for performance reasons.Wie verbessert die Trennung die Leistung (vorausgesetzt, die Spalten werden immer bei jedem Zugriff auf die Haupttabelle aufgerufen)?Die Hauptgründe, warum Sie eine Eins-zu-Eins-Zuordnung verwenden würden, um eine große Tabelle in zwei Teile zu teilen, sind beispielsweise Leistungsgründe:
a) Die Tabelle enthält Binär- / Clob / Blob-Daten in einer Tabelle, auf die häufig zugegriffen wird, wodurch die Leistung verlangsamt wird, da die großen Spalten unterschiedlich behandelt werden.
b) Die Tabelle enthält viele Spalten, auf die von verschiedenen Abfragen zugegriffen wird. Daher wird die Leistung beeinträchtigt. Daher würden Sie verwandte Spalten in eine separate Tabelle verschieben, um die Zugriffsleistung zu verbessern
Das Vorhandensein vieler ganzzahliger Spalten rechtfertigt jedoch nicht den zusätzlichen Aufwand, die Tabelle in separate Tabellen aufzuteilen und abzufragen.
quelle