key-value/DBM/OO/Hash/Non-relational Datenbankendesign?


#1

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


Gruß,
Andreas


#2

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:

Album zugewiesen werden kann ist erstmal egal.
store[key] = Marshal.dumb(album)
Wie sind eure Erfahrungen damit?

Gruß,
Andreas


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