Ja, die Probleme hab ich auch, modellierung mit nicht-relationalen
Datenbanken ist man irgendwie nicht gewöhnt: Wenn ich das richtig
verstehe, dann gibt's da zwei Optionen, die ungefähr den Objekt-
Relationen entsprechen:
- Nesting: Dabei würde man ein Dokument "Album" anlegen und dann die
einzelnen Fotos da ablegen ("einkleben"?!)
- referenzen: dabei legt man das Foto an und legt nur die UUID im
"Album" - das kommt der traditionellen Referenz wohl am nächsten.
Für CouchDB gibt's eine längere Diskussion über das für und wider
beider Ansätze:
http://www.cmlenz.net/archives/2007/10/couchdb-joins
Und ein recht gutes Tutorial dazu hier (und zu den verschiedenen rails/
couchdb-Ansätzen):
http://aimee.mychores.co.uk/2008/09/08/post/323/couchdb-on-rails-part-3-of
ActiveCouch (http://github.com/arunthampi/activecouch/tree/master) und
couchfoo (http://github.com/georgepalmer/couch_foo/tree/master)
versuchen, die couchdb auf activerecord abzubilden und implementieren
(wenn ich das richtig überblicke) joins mittels uuids... Wie sinnvoll
diese Implementierungen sind, lass ich mal dahin gestellt: Wenn's wie
active_record aussieht und sich mit Einschränkungen auch so verhält,
dann kann man eigentlich auch gleich eine relationale DB und richtiges
ActiveRecord nehmen, oder?! Mir gefallen eigentlich die close-to-the-
metal Ansätze von couchrest (http://github.com/jchris/couchrest/tree/master
) besser: Damit kann man die Vorteile (hierarchisch, schemalos,
attachments usw.) von solchen dokument-zentrierten Datenbanken eher
ausnutzen, als wenn man sie hinter einer Fassade versteckt, die
eigentlich für relationale Datenbanken gedacht war...
just my 2 cents
stefan
Am 28.03.2009 um 19:41 schrieb Andreas Haller:
Hallo
ich wollte mal aufhöhren mit dem ganzen SQL-Wahnsinn und eine Nicht-
relationale Datenbank ausprobieren.
Meine Wahl wäre da TokyoCabinet (http://
tokyocabinet.sourceforge.net), man könnte aber auch CouchDB oder so
nehmen glaube ich.
Als Startpunkt möchte ich eine Fotoalbum-Anwendung bauen. Es gibt
also Fotos und Alben. Ob jedes Foto genau einem oder mehreren/keinem
Album zugewiesen werden kann ist erstmal egal.
Jetzt die Frage:
Wie speichert man die Foto - Album Beziehungen?
Folgendes fällt mir dazu ein
1. Jedes Album wird als solches gespeichert
Ich speichere eine komplette Album-Instanz in der Datenbank,
gemarshaled, komplett mit dem .fotos Array
album.fotos # => [Foto, Foto, Foto, Foto]
store[key] = Marshal.dumb(album)
2. Ich speichere nur Foto Objekte und sortiere sie nach Album-Namen
Wenn ich ein Album umbennen möchte, ratter ich durch alle
jeweiligen Fotos und ändere den Album-Namen.
store[key] = { foto: mein_foto, album_name: ""}
Was denkt ihr?
Habt ihr schonmal was mit so welchen Datenbanken gemacht? (Key/
Value.. wie nennt man das?)
Wie sind eure Erfahrungen damit?
Ich finde den Ansatz von Dokument-orientierten Datenbanken
eigentlich gut - Speicher.. das da! Anstatt speicher.. hier und da
und da und da was. Aber es ist trotzdem nicht einfach zu verstehen.
Ein paar links zum Thema
http://tokyocabinet.sourceforge.net/index.html
http://blag.ahax.de/post/90023607/exploring-tokyo-cabinet
http://github.com/wycats/moneta
Gruß,
Andreas
_______________________________________________
rubyonrails-ug mailing list
[email protected]
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 [email protected]
www.vierundsechzig.de
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/listinfo/rubyonrails-ug
