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
http://drawohara.com/post/53975615/rails-dynamic-properties-for-activerecord-objects
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 @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama
