Redundanz und Performance

[daWonderer]

Hallo,

ich habe zwei Konzepte wie ich eine Struktur abbilden möchte.

Jetzt frage ich mich, ob ich Redundanz in Kauf nehmen soll weil z.B. die Performance leiden könnte.

[ ID, STRING, WERT ]

STRING ist einmalig je ID

oder lieber 2 Tabellen?

[ ID, STRING_ID, WERT ] 
[ STRING_ID, STRING ]

Ist die 2. Möglichkeit bei großen Datenbeständen durch Nutzung eines JOIN aus Performancegründen evtl. nicht zu empfehlen?

greetz Ralf

[Christian Marquardt]

Sollte nicht vielmehr die Frage sein, ob STRING noch irgendwo anders genutzt wird?

Wenn nein, warum dann eine 2. Tabelle?

[daWonderer]

Sollte nicht vielmehr die Frage sein, ob STRING noch irgendwo anders genutzt wird?

Die Strings sind Konstanten/Aliase die im Skript verwendet werden.
Diese Aliase sollen in der Tabelle den IDs zugeordnet werden.

In Hinsicht des Speicherplatzbedarfs ist es besser diese Konstanten auszulagern in eine eigene Tabelle.
Gibt es jedoch bei dieser Methode Nachteile bei großen Datenbeständen durch die Verwendung von JIONS bzgl. der Performance?

Ist es überhaupt manchmal besser Redundanz zuzulassen aus Performancegründen?

[dimitri]

Ist es überhaupt manchmal besser Redundanz zuzulassen aus Performancegründen?

Durchaus. Eine Datenbank, die sich in der Dritten oder einer höheren NF befindet ist ab einer bestimmten Anzahl von Entitäten und Daten nicht mehr wirklich verwendbar was Performance und auch Komplexität entspricht.

Daher wird als letzter Schritt der Modellierung auch immer eine gezielte Denormalisierung vorgenommen.

Für deine 2 Tabellen sehe ich da aber noch keinen Bedarf dafür.

Dim

[daWonderer]

Daher wird als letzter Schritt der Modellierung auch immer eine gezielte Denormalisierung vorgenommen.

Interessant, das wusste ich noch nicht.

Danke!

greetz Ralf...

[Jürgen Thomas]

Hallo Ralf,

Gibt es jedoch bei dieser Methode Nachteile bei großen Datenbeständen durch die Verwendung von JIONS bzgl. der Performance?

Das hängt wie häufig davon ab, wie oft eine solche Situation tatsächlich vorkommt. Wenn du "Angst" darum hast, dann benutze doch eine VIEW mit dem JOIN, dann ist das Verfahren in der DB bereits fest verankert.

Ist es überhaupt manchmal besser Redundanz zuzulassen aus Performancegründen?

Selbstverständlich, das betrifft z.B. fast jede Adressendatei. Jede Kombination PLZ + Ortsname gibt es nur einmal, diese gehören deshalb in eine separate Tabelle. (Eigentlich ist die Normalisierung noch weiter zu treiben, aber zur Erläuterung des Prinzips genügt das.) Dennoch stehen diese Angaben direkt bei jeder Adresse.

Ich würde "deine" Strings übrigens nicht auslagern.

Gruß Jürgen

[daWonderer]

Hallo,

danke für deine Antwort.

Wenn du "Angst" darum hast, dann benutze doch eine VIEW mit dem JOIN, dann ist das Verfahren in der DB bereits fest verankert.

Inwiefern wird bei einer VIEW dieser SELECT verankert? ( ich schau auch bei Gelegenheit im Netz bin zur Zeit am arbeiten )

Jede Kombination PLZ + Ortsname gibt es nur einmal, diese gehören deshalb in eine separate Tabelle. (Eigentlich ist die Normalisierung noch weiter zu treiben, aber zur Erläuterung des Prinzips genügt das.) Dennoch stehen diese Angaben direkt bei jeder Adresse.

Ok, die Auslagerung macht Sinn wenn man bei großen Datenbeständen die Relation der PLZ <-> Ortsnamen braucht ohne weitere Daten.

Ich würde "deine" Strings übrigens nicht auslagern.

Ok

greetz Ralf...

[fanderlf]

...Das hängt wie häufig davon ab, wie oft eine solche Situation tatsächlich vorkommt. Wenn du "Angst" darum hast, dann benutze doch eine VIEW mit dem JOIN, dann ist das Verfahren in der DB bereits fest verankert...

Es ist aber dann auch egal ob der JOIN in einer View statt findet oder vom Programm getriggert wird. Auch ein View wird bei jeder SQL Abfrage neu berechnet. Im Endeffekt ist ein View somit nichts anderes als eine gespeicherte SQL Abfrage und bringt meines Wissens performancetechnisch nichts.