nicht angemeldet
MySQL - Zusätzliche Eigenschaften definieren
Beim Entwerfen eines Template-Systems bin ich auf folgendes Problem gestossen:
Kann ich für eine Spalte einer MySQL-Datenbank benutzerdefinierte Parameter angeben? Diese benötige ich um zusätzliche Informationen zum Inhalt des Feldes anzugeben(z.B. ob der Inhalt des Feldes ein Pfad zu einer Datei ist und so eine Datei included werden muss, oder ob es sich um einen Text handelt, welcher direkt übernommen werden kann.)
Muss ich da eine zusätzliche Tabelle machen und darin definieren, dass es sich bei Spalte x um Pfadangaben und bei Spalte y um Text handelt?
Bisher habe ich z.B ein "p_" oder ein "t_" vor den Spaltenname gefügt. So konnte das PHP-Script auslesen ob es sich um ein Feld mit Pfadangaben oder um einfachen Text handelt.
Da das ganze jetzt ein grösseres Projekt wurde und vielmehr Eigenschaften definiert werden müssen ist das aber zu umständlich.
Gibt es eine Lösung? (Abgesehen von einer zusätzlichen Tabelle?)
-
Halihallo Daniel
Kann ich für eine Spalte einer MySQL-Datenbank benutzerdefinierte Parameter angeben?
Nein. Eine Datenbank ist zum Abbilden staatischer Information gedacht. Das was du
preferierst, wäre ein Schema dynamischer Information.Diese benötige ich um zusätzliche Informationen zum Inhalt des Feldes anzugeben(z.B. ob der Inhalt des Feldes ein Pfad zu einer Datei ist und so eine Datei included werden muss, oder ob es sich um einen Text handelt, welcher direkt übernommen werden kann.)
Datenbanken halten sich (zumindest die meisten) an die sogenannte 1 Normalform. Diese
verbietet, dass einzelne Attribute (Zellen) mehrwertig sind. Eine Zelle darf lediglich
einen Wert enthalten.Muss ich da eine zusätzliche Tabelle machen und darin definieren, dass es sich bei Spalte x um Pfadangaben und bei Spalte y um Text handelt?
Nicht umbedingt. Die Angabe kann auch in der selben Tabelle manifestiert sein.
id | x | type
1 | value1 | pfaddu hast ein Attribut x und möchtest den Typ desselben definieren, dies liesse sich
überx | type_of_x
abbilden. Wobei type_of_x z. B. ein SET ist. SET('string','array','pfad',...)
Bisher habe ich z.B ein "p_" oder ein "t_" vor den Spaltenname gefügt. So konnte das PHP-Script auslesen ob es sich um ein Feld mit Pfadangaben oder um einfachen Text handelt.
das ist andere Möglichkeit, ja.
Da das ganze jetzt ein grösseres Projekt wurde und vielmehr Eigenschaften definiert werden müssen ist das aber zu umständlich.
Das Datenbankmodell sollte redesigned werden um diesen neuen Ansprüchen zu genügen und dies auf alle Zeit, falls die Änderungen nicht mehr sinnvoll abbgebildet werden können.
Gibt es eine Lösung? (Abgesehen von einer zusätzlichen Tabelle?)
Jein. Siehe oben.
Viele Grüsse
Philipp
-
Hallo,
Nicht umbedingt. Die Angabe kann auch in der selben Tabelle manifestiert sein.
id | x | type
1 | value1 | pfadwürde das aber nicht gegen die zweit oder dritte Normalform
(ich weiss gerade nicht mehr welche welche war) verstossen???
Attribut ist von einem anderen abhängig...
(ja, ich weiss, in manchen Fällen muss denormalisiert werden)Gruß vom Horst der die "in anderer Tabelle"-Methode bevorzugen würde
-
Halihallo Horst
Nicht umbedingt. Die Angabe kann auch in der selben Tabelle manifestiert sein.
id | x | type
1 | value1 | pfadwü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
-
-
-
Halihallo Daniel
[...]
Doppelpostings bitte unterlassen. Dieses Posting von mir beweist, dass wir auch nach ganz
unten lesen. Zudem kann es vorkommen, dass man mal für drei Stunden keine Antwort erhält.
Ein erneutes Posten derselben Frage ist erst gerechtfertigt, wenn der alte Thread
bereits im Archiv gelandet ist. Danke!Duplikat von:
[pref:t=34861&m=189875]Viele Grüsse
Philipp