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 <[EMAIL PROTECTED]>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 > > > 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 > > > >
