couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ayende Rahien" <>
Subject Re: When to use CouchDB, when not to...
Date Mon, 13 Oct 2008 23:08:33 GMT
Trying to do dynamic entities in the DB tends to be a major PITA in any high
perf scenario

On Mon, Oct 13, 2008 at 11:09 PM, ara.t.howard <>wrote:

> On Oct 12, 2008, at 1:28 PM, Lance Pollard wrote:
>  Maybe it could be such that:
>> -MySQL handles entities that have 1) static properties (columns of tables
>> are pretty much constant, like a "user_account" or "contact_address"
>> are…),
>> and 2) static (username) or dynamic (chunk of text) values.
>> -CouchDB handles things that have 1) dynamic properties (columns in
>> relational database become "keys" or whatever in Couch, and these keys
>> aren't fixed but can change from resource to resource), and 2) dynamic
>> values only. And 3) Couch would handle all uploaded/attachment data
>> because
>> many documents, even if they are the same type (image, video, word…),
>> might
>> have different properties depending on the situation.
>> I've just been trying to think how you could manage 10s or 100s of
>> potential
>> "entities/tables" in a database and wanted to pass it your way to get your
>> input.
>> If CouchDB handled things that only had "dynamic" properties, then an
>> "image" entity for example could have [title, caption, size,
>> attachment_fu.stuff] in one case and [title, tags] in another, or
>> whatever;
>> there is no need to have a single "Images" table with a specified set of
>> properties (rows).  Image properties or rows can instead be dynamic.  But
>> what entities do we choose to be dynamic?
>> So instead of having single inheritance in relational databases and huge
>> table with tons of null columns, you could have, basically, a
>> table-per-asset, or a document--that's what Couch is.  But what kind of
>> structure do you apply to Couch documents?  And what entity should be
>> placed
>> in Couch vs. MySQL?  Maybe all file-uploads can go to Couch and all
>> structured-mostly-unchanging entities, like user accounts, can go to
>> MySQL?
> slightly OT, but it's not really true that you can't handle dynamic
> properties with a RDBMS.  you just have to normalize even your columns are
> child records.  i have a plugin for AR which does just that, read this to
> see what mean
> the win for couchdb, IMHO, really comes from storing object *graphs* as one
> entity.  that and the fact that it enables, for really the first time,
> *true* MVC arch.  that is to say javascript (the view) can see the model.
>  most people ignore this link in the MVC triangle and it's why the pattern
> can feel so forced at times.  in MVC the views is *supposed* to be able to
> see the model.  with couch db it can, and easily at that.
> cheers.
> a @
> --
> we can deny everything, except that we have the possibility of being
> better. simply reflect on that.
> h.h. the 14th dalai lama

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message