Attribute in extra Model


#1

Hi,

ich habe folgendes vor und hoffe Ihr kennt eine gute Lösung. 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. Evtl gibt es ja schon ein Plugin. Ich selber hab auch
schonmal daran gedacht accepts_nested_attributes_for zu verwenden mit
HasOne Verknüpfungen. Allerdings wäre es mir lieber wenn die Key-Liste
dynamisch bleibt, außerdem wäre es auch nicht ganz dry alle attribute im
model festzulegen.

schöne grüße und danke für eure hilfe


#2

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:removed_email_address@domain.invalid
http://www.schuerig.de/michael/