Forum: Rails Germany key-value/DBM/OO/Hash/Non-relational Datenbankendesign?

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

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/co...

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:

> Album zugewiesen werden kann ist erstmal egal.
>     store[key] = Marshal.dumb(album)
> Wie sind eure Erfahrungen damit?
>
> Gruß,
> Andreas
> _______________________________________________
> 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