Philipp Hasenfratz: MySQL - Zusätzliche Eigenschaften definieren

Beitrag lesen

Halihallo Horst

Nicht umbedingt. Die Angabe kann auch in der selben Tabelle manifestiert sein.

id   |   x    |   type
1    | value1 |   pfad

würde das aber nicht gegen die zweit oder dritte Normalform
(ich weiss gerade nicht mehr welche welche war) verstossen???

Nein. Type ist weder funktional von x abhängig, noch ist x von type abhängig. Das eine
oder andere Attribut spezifiziert das andere nur und ist somit eine Art "Erweiterung".
Um das etwas bildlich auszudrücken: x und type zusammen ist _eine_ Information, welche
einfach auf zwei Attribute "aufgesplittet" wird. Dies verstösst nicht gegen die zweite,
noch die dritte Normalform und ist sogar sinnvoll.
*Kaffepause*
Hmmm... Deine Aussage trifft zu, wenn ein Attribut vom anderen "hergeleitet" werden kann.
z. B. wenn x eine Zahl enthält, muss type den Wert "Zahl" annehmen. In diesem Sinne hast
du recht; aber die Aufgabenstellung sagt ja aus, dass der type eben nicht implizit
gegeben ist und somit auch keine funktionale Abhängigkeit besteht.

BTW: Es wäre die dritte NF. Funktionale Abhängigkeiten zwischen Attributen, welche nicht
Teilmenge des Primärschlüssels/Schlüsselkandidaten sind. Die zweite sagt lediglich aus,
dass jedes Attribut entweder Bestandteil des PrimaryKey, oder von diesem
voll funktional abhängig sein muss.

(ja, ich weiss, in manchen Fällen muss denormalisiert werden)

Stimmt. Schematas in Normalform zu haben ist zwar wünschenswert, aber man muss sich
bewusst sein, dass dies aus Sicht der Performance oftmals nicht sinnvoll ist. Ein
Schemata auf zwei aufzuteilen, heisst JOIN um diese wieder zu vereinen. JOIN's sind
langsam. Die Praxis zeigt oft, dass Kompromisse gebraucht werden.

Gruß vom Horst der die "in anderer Tabelle"-Methode bevorzugen würde

Bedingt einverstanden.  [will heissen, normalerweise gebe ich dir recht.]

Viele Grüsse

Philipp