Re: Attribute in extra Model


#1

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 :smiley:

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 :smiley:

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 S.” removed_email_address@domain.invalid
Gesendet: 02.06.09 20:55:07
An: removed_email_address@domain.invalid
Betreff: Re: [Rubyonrails-ug] Attribute in extra Model


#2

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 :smiley:

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


#3

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-an-entity-attribute-value-data-model-for-flexible-metadata-in-a-digital-asset-management-system/)

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-bindings-accessing-jenas-feature-rich-rdf-api-from-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 :slight_smile:

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:removed_email_address@domain.invalid
rubyonrails-ug mailing list
removed_email_address@domain.invalid
http://mailman.headflash.com/listinfo/rubyonrails-ug


stefan frank


software&service
weberstr. 10
69120 heidelberg
tel. +49 (0) 6221 7277049
mobil +40 (0) 173 2383390
mail removed_email_address@domain.invalid