Objekte in DB speichern
am 28.12.2005 16:13:12 von Hendrik Pilz
Ich würde gerne mal Standpunkte zu folgendem Thema lesen:
Macht es Sinn, serialisierte Objekte in der Datenbank zu speichern,
statt für jede Objekteigenschaft ein Feld in der Tabelle anzulegen? Man
hat nur Felder, nach denen direkt gesucht werden kann (mit Indizes), und
ein Feld mit dem Objekt, dass durchaus noch weitere Eigenschaften als
die Suchfelder haben kann.
Welche Vor- und Nachteile hat diese Art der Datenverwaltung?
Gruß, Hendrik
Re: Objekte in DB speichern
am 28.12.2005 16:53:11 von Niels Braczek
Hendrik Pilz schrieb:
> Macht es Sinn, serialisierte Objekte in der Datenbank zu speichern,
> statt für jede Objekteigenschaft ein Feld in der Tabelle anzulegen? Man
> hat nur Felder, nach denen direkt gesucht werden kann (mit Indizes), und
> ein Feld mit dem Objekt, dass durchaus noch weitere Eigenschaften als
> die Suchfelder haben kann.
>
> Welche Vor- und Nachteile hat diese Art der Datenverwaltung?
(Echte) Vorteile sehe ich nicht.
Nachteile dagegen einige. Durch die entstehenden Redundanzen ist zB.
eine sinnvolle Datenpflege unmöglich. Die Gefahr von Inkonsistenzen
steigt ins Unkontrollierbare. Kurzum: Alles, was durch Normalisierung[1]
vermieden wird.
fn1. http://de.wikipedia.org/wiki/Normalisierung_%28Datenbank%29
MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · E-Commerce · Mambo Content Management |
`----------------------------------------------------------- -----´
Re: Objekte in DB speichern
am 10.02.2006 09:25:28 von Mirko Glotz
Hendrik Pilz am Mi, 28 Dez 2005 15:13:12 GMT:
> Macht es Sinn, serialisierte Objekte in der Datenbank zu speichern,
[ ... ]
> Welche Vor- und Nachteile hat diese Art der Datenverwaltung?
Hallo Hendrik
Also ich persönlich würde das selbst nur bei bestimmten Datensätzen
machen und tue es auch mit Erfolg.
Im konkreten Fall betrifft das Einstellungen innerhalb des Systems, in
dem User bestimmen können welche Daten öffentlich sein dürfen und welche
nicht. Da hier keinerlei Suche über die Datensätze nötig ist, wäre es aus
meiner Sicht unnötiger Aufwand.
Auch lassen sich derartige Dinge sehr leicht nur innerhalb der Scripte
erweitern oder verändern, so man den Schlüssel zum Feld mit speichert,
ohne Veränderungen an den Tabellen vornehmen zu müssen. Ich habe es
ansatzweise so gelöst.
$serial = array("username"=>1,"email"=>0,"vorname"=>1,"nachname=>0);
Da die Keys in der eigentlichen Tabelle für die entsprechenden
Tabellenspalten benutzt werden als auch in den Formularfeldern, kann man
hier recht einfach die Zuordnungen und Zugriffe der User steuern.