couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ara.t.howard" <>
Subject Re: When to use CouchDB, when not to...
Date Mon, 13 Oct 2008 20:09:05 GMT

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.


a @
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama

View raw message