Ist die Eins-zu-Eins-Beziehung normalisiert?

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.

— Googlebot
quelle

'Normalisiert' bedeutet erste Normalform (1NF) und ist eine Grundvoraussetzung des relationalen Modells. "Vollständig normalisiert" bedeutet 5NF oder höher. Ihre vorgeschlagene "Eins-zu-Eins-Beziehung" -Tabelle hat eine bessere Chance, in einer höheren Normalform (möglicherweise sogar in 6NF) zu sein als Ihre aktuelle, da sie zerlegt ist! Welche normalen Formen erfüllt Ihre vorhandene Tabelle?

— Tag, wenn

@onedaywhen Wie viele andere folge ich der Normalisierung nicht Schritt für Schritt, da manchmal auch eine De-Normalisierung hilfreich ist. Im Allgemeinen sollte die gesamte Datenbank einen Normalisierungsgrad zwischen 3NF - 5NF haben (ich habe immer ein Problem mit 4NF!)

— Googlebot

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.

— Joel Brown
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)?

— Gili

@Gili - Wenn Ihre Annahme wahr wäre, würde dieser Fall nicht zutreffen. Durch das Trennen großer und selten benötigter Spalten können mehr Zeilen auf eine Seite passen, wodurch die häufig verwendeten Spalten schneller abgerufen werden können. Offensichtlich wäre das Lesen der getrennten Spalten zusammen mit den häufig verwendeten Spalten langsamer, da eine Verknüpfung erforderlich ist.

— Joel Brown

Ich möchte aus Entwurfsgründen (Trennung von Bedenken, vermehrte Wiederverwendung von Code) entlang häufig verwendeter Spalten trennen. Hat jemand eine Schätzung der Kosten solcher Joins veröffentlicht? Sind sie vernachlässigbar oder sollte ich mir langfristig Sorgen machen?

— Gili

@Gili - re: die Kosten für Joins: Es gibt keine richtige Antwort auf diese Frage außer "es kommt darauf an". Die Beitrittskosten werden von vielen Faktoren beeinflusst. Ob sie vernachlässigbar sind, ist noch schwerer zu beantworten, denn das ist letztendlich subjektiv. Der beste Weg, um Ihre Frage zu beantworten, besteht darin, einige Testdaten zu verspotten und Volumentests durchzuführen. Probieren Sie es in beide Richtungen aus und prüfen Sie, ob Sie anhand realer Datenmengen den Unterschied feststellen können (was auch immer dies für Ihre Anwendung bedeutet).

— Joel Brown

Ich habe es getan und überraschende Ergebnisse erzielt: dba.stackexchange.com/q/74693/4719 Ich gebe zu, dass dies kein typisches Beispiel für Normalisierung ist, aber es zeigt nicht, dass JOINs (noch) sehr teuer sind.

— Gili

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.

— Stephen Senkomago Musoke
quelle

Sehr guter Punkt zur Klärung des Problems!

— Googlebot