Forum: Rails Germany Attribute in extra Model

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
38c4f43b88d569219a95e8ddb71375e7?d=identicon&s=25 Marco Scholl (Guest)
on 2009-06-02 20:27
(Received via mailing list)
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
Bce1d1b7c3ec7b577dcb42e254899e6b?d=identicon&s=25 Michael Schuerig (Guest)
on 2009-06-02 20:55
(Received via mailing list)
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 Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/
This topic is locked and can not be replied to.