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
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
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.” [email protected]
Gesendet: 02.06.09 20:55:07
An: [email protected]
Betreff: Re: [Rubyonrails-ug] Attribute in extra Model
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:
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
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.
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
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