On Tuesday 02 June 2009, Marco Scholl wrote:
Ich bau gerade an einem Portal in dem es User gibt. Die User sollen
Informationen/Attribute haben. Diese Attribute sollen aber in einer
extra Tabelle gespeichert werden. (z.B. user_id, key, value). Grund
ist, es soll später ein weitere Liste geben wo gesagt werden darf wer
darf welche Attribute sehen. Die Attribute selbst sollen aber über
ein 1 Formular gepflegt werden und will vermeiden jedes Attribute
selbst zu setzten, da es nicht Dry wäre. Wie würdet Ihr das am
sinnvollsten machen. Dieses Attributkonzept benötige ich noch an mehr
stellen, daher erstmal das ganze allgemein gefragt.
Bist du sicher, dass du ein solches Datenmodell brauchst? Selbst wenn du
in der Datenbankstruktur extrem flexibel bist, mußt du irgendwo oben
drüber irgendwie das Schema deiner Daten definieren, sonst kannst du
damit nichts anfangen.
Für einen vermeintlichen Gewinn an Flexibilität zahlst du einen hohen
Preis für die Entwicklung eines eigenen Systems in dem das Schema in
Metadaten definiert werden kann. Und du handelst dir massive
Performance-Nachteile ein, weil du für jeden Zugriff auf eines deiner
Objekte die Bestandteile in vielen Joins zusammenpuzzlen mußt.
Da halte ich es für sehr fraglich, ob der Vorteil an Flexibilität
gegenüber dem ohnehin schon sehr flexiblen Rails das wert ist. Falls du
während der Laufzeit des Systems das virtuelle Datenmodell ändern mußt
(wirklich mußt, nicht nur gerne würdest), dann führt kein Weg an deinem
System vorbei. Ansonsten würde ich darauf verzichten.
Als Zwischending könntest du prüfen, ob es sinnvoll möglich ist die
generische Key-Value-Speicherung hinter einem Datenbank-View zu
verstecken. Vielleicht bist du ja auch mit einem der derzeit angesagten
Key-Value-Stores besser bedient als mit einer relationalen Datenbank.
Ich schreibe das mit einem Projekt im Hinterkopf, an dem ich vor 10
Jahren beteiligt war. Wir dachten auch, wir bräuchten ein derartig
flexibles Datenmodell. Tatsächlich war es aber so, dass wir keine
ausreichende Ahnung hatten, was die tatsächlichen Anforderungen waren,
und sind darüber in die Generizität geflüchtet. Typisch für Techniker,
aber die falsche Lösung.
Michael
–
Michael S.
mailto:[email protected]
http://www.schuerig.de/michael/