Forum: Rails Germany Re: Attribute in extra Model

Hi,

auch ich bin seit Jahren als Entwickler tätig und mir sind die Risiken 
sehr
bewusst. Ich habe mich auch noch garnicht festgelegt, sondern Versuche
erneut das alte leidige Thema nochmals zu durch denken. Allerdings teile 
ich
die Meinung über ich die "Massiven Performenceproblem" nicht, da ich sowiso
alle Attribute mit 1 Select pro User laden würde. 

Nun nochmal zum Problem selbst:

Eigentlich werden keine Datenfelder/Attribute zur Laufzeit geändert,
aber ich habe mir erhofft, da es sich um einen railsbasierendes 
Framework handelt,
die Felder schön in einer Yaml die beim Serverstart geladen wird zu 
verwalten.
Brauche ich kurzfristig ein neues Feld, so lege ich es in der Yaml-File 
an,
sage auch noch ob dieser Wert im Profil angezeigt werden soll,
ob er über die Privatsphäreneinstellung sichbar/unsichbar gemacht werden soll.

Würde ich das ganze nun schön sauber in Spalten trennen, was definitiv schöner wäre,
müsste ich mehrere Migrations anlegen um überall die Felder anzulegen.

Gut jetzt könnte ich dafür Generatoren bauen :D

Kurz gesagt ich muss A flexible bleiben, und B es sollte DRY ML bleiben.
Ich will vermeiden um 1 Feld anzulegen nachher 3-4 Tabellen anzupassen.

Zum Thema View:

Ich denke das ist unnötig, da der View auch nur ein Select ist, und mein 
Problem
weniger das laden der Attribute byUserId ist. Immer diese 
Designentscheidung :D

Vtl hab Ihr ja noch weitere Ideen wie man das Problem sauberer lösen kann 
oder
also tipps wie man das Vorhaaben so sauber umsetzten kann.

Erstmal danke Michael für deinen Post

lg marco




> -----Ursprüngliche Nachricht-----
> Von: "Michael Schuerig" <michael@schuerig.de>
> Gesendet: 02.06.09 20:55:07
> An: rubyonrails-ug@headflash.com
> Betreff: Re: [Rubyonrails-ug] Attribute in extra Model

On Tuesday 02 June 2009, Marco Scholl wrote:
> auch ich bin seit Jahren als Entwickler tätig und mir sind die
> Risiken sehr bewusst. Ich habe mich auch noch garnicht festgelegt,
> sondern Versuche erneut das alte leidige Thema nochmals zu durch
> denken. Allerdings teile ich die Meinung über ich die "Massiven
> Performenceproblem" nicht, da ich sowiso alle Attribute mit 1 Select
> pro User laden würde.

Ich hatte schon vorausgesetzt, dass du alle Attribute in nur einem
Zugriff auf die DB einsammelst. Du brauchst aber pro Attribut einen Join
und damit können die verschiedenen DBMS unterschiedlich gut umgehen.
Bevor du viel Arbeit in eine flexible Lösung steckst, die nachher nicht
die benötigte Leistung bringen kann, teste das lieber erst unter
halbwegs realistisch simulierten Bedingungen (und berichte über die
Ergebnisse ;-)) Es ist gar keine Frage, dass es möglich ist, 10 Joins in
einer Query zu haben; fraglich ist aber, wie sich das auf die
Performance auswirkt.

Apropos Query: Da Queries auf den flexiblen Attributen ohnehin kaum
möglich sind, kannst du vielleicht auch ganz darauf verzichten. Falls
das so ist, kannst du diese zusätzlichen Attribute auch serialisiert in
einem serialisierten Hash unterbringen:

http://github.com/kylecrum/flex_fields

> Nun nochmal zum Problem selbst:
>
> Eigentlich werden keine Datenfelder/Attribute zur Laufzeit geändert,
> aber ich habe mir erhofft, da es sich um einen railsbasierendes
> Framework handelt, die Felder schön in einer Yaml die beim
> Serverstart geladen wird zu verwalten. Brauche ich kurzfristig ein
> neues Feld, so lege ich es in der Yaml-File an, sage auch noch ob
> dieser Wert im Profil angezeigt werden soll, ob er über die
> Privatsphäreneinstellung sichbar/unsichbar gemacht werden soll.

Experimentell würde ich das so angehen:

- In config/flexischema.yaml für jede Modelklasse die flexiblen
Attribute einschließlich Typ definieren.
- Beim Start der App für jede Modelklasse aus den Attribute die
benötigten Joins erzeugen und mit diesen einen default_scope auf der
Klasse definieren. Alternativ #find "geeignet" überschreiben.
- Für jedes Attribut reader/writer-Methoden erzeugen, die auch die
Typkonvertierung übernehmen.
- Die Metadaten über die Sichtbarkeit ins Access Control-System
eintragen.

> Würde ich das ganze nun schön sauber in Spalten trennen, was
> definitiv schöner wäre, müsste ich mehrere Migrations anlegen um
> überall die Felder anzulegen.
>
> Gut jetzt könnte ich dafür Generatoren bauen :D

Es hat mich gerade 2 Sekunden gejuckt, genau das zu tun. Mit PostgreSQL
kannst du die DB-Struktur transaktional ändern, also im Prinzip im
Betrieb, obwohl das nötige grobkörnige Locking sicher den Durchsatz
während dessen erheblich einschränkt.

Michael

--
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

hmm, das lief früher mal unter dem Schlagwort EAV 
(http://en.wikipedia.org/wiki/Entity-Attribute-Value_model
), ist aber wohl ein bisschen aus der Mode gekommen. Aber es gibt
immer noch den einen oder anderen, der damit experimentiert (z.B. 
http://www.stonemind.net/blog/2007/07/13/exploring...)

Grund dafür scheint mir zu sein, dass die meisten DBs mittlerweile so
flexibel sind, dass auch das on-the-fly-ändern des DB-Schemas schon
irgendwie funktionert, wenn's denn sein muss -  das wäre die Lösung
von unten: Die Lösung von oben wären dann semantische reichere
Frameworks wie RDF/OWL. Da kümmern sich dann andere darum, dass das
ganze halbwegs performant bleibt: mit Jena&SPARQL gibt's da auch
komplette Lösungen für die Persistenz und das Querying 
(http://jena.sourceforge.net/
, 
http://www.thewebsemantic.com/2008/01/05/jena-ruby...)
  - auch nicht so richtig erfolgreich scheint mir, weil das für die
meisten Anwendungen schon zu kompliziert ist (obwohl man Firefox schon
eher zu den erfolgreichen Projekten zählen kann :)

Für den Hausgebrauch tut es vielleicht zunächst mal eine schema-lose
DB wie CouchDB? Das scheint mit da immer noch ein vertretbarer
Mittelweg zu sein, und gerade wenn es darum geht, viele
zusammengehörige Attribute mit einem Schlag aufzusammeln, dann bringt
CouchDB gute Performance...

GrüßeStefan



Am 02.06.2009 um 21:23 schrieb Marco Scholl:

> Nun nochmal zum Problem selbst:
> werden soll.
> anzupassen.
> also tipps wie man das Vorhaaben so sauber umsetzten kann.
>> Gesendet: 02.06.09 20:55:07
>>> darf welche Attribute sehen. Die Attribute selbst sollen aber über
>>> ein 1 Formular gepflegt werden und will vermeiden jedes Attribute
>>
>> (wirklich mußt, nicht nur gerne würdest), dann führt kein Weg an  
>> Jahren beteiligt war. Wir dachten auch, wir bräuchten ein derartig
>> mailto:michael@schuerig.de
> rubyonrails-ug mailing list
> rubyonrails-ug@headflash.com
> http://mailman.headflash.com/listinfo/rubyonrails-ug

----
stefan frank
vierundsechzig.de
software&service
weberstr. 10
69120 heidelberg
tel. +49 (0) 6221 7277049
mobil +40 (0) 173 2383390
mail s.frank@vierundsechzig.de
www.vierundsechzig.de