couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gaspard Buma <>
Subject Re: couchdb as backend for a CMS
Date Thu, 29 Jan 2009 17:50:20 GMT
It's funny how the world goes around.... The "query" model in couchDB
is exactly what FileMaker has been forcing developers to use for more
then ten years:

Define calculation fields that act as multi-key indexes.

With clever hacks, I managed to build complete ERPs with FileMaker, so
I'm sure that couchDB could support the same kind of applications
(with added content flexibility and a better architecture) so the
concepts seem quite familiar.

If zena was a CMS with fixed relations (a post has comments, ...), it
would be a no brainer: couchDB would be a clear winner. But since an
important aspect of zena is the dynamic nature of the objects involved
and their relations (expressed with pseudo sql: and since this is hard to model with views
I will continue to use a traditional RDMS until a database comes out
that supports both worlds (dynamic content definition with relational


On Thu, Jan 29, 2009 at 6:15 PM, Dean Landolt <> wrote:
> On Thu, Jan 29, 2009 at 10:35 AM, Gaspard Buma <>wrote:
>> But the example (comments in posts) is a "belongs_to" relation (no
>> need for an external join table). Is there any example with a "has
>> many and belongs to many" example ?
>> My feeling is that a habtm relation could be modeled with something like:
>> {
>>  "name": "John",
>>  "friends": ["Paul", "Mike", "Carla"]
>> }
>> Then you index on friends:
>> function(doc) {
>> {
>>    emit(friend, doc);
>>  });
>> }
>> That's fine (except you have to update "John" and "Carla" if they are
>> not friends anymore). But what if you move one level further and need
>> to see the latest posts of your friends ?
>> {
>>  "title": "Learning how to surf",
>>  "author": "Carla"
>> }
>> You can get the latest posts from "Carla" easily. You can get the list
>> of your friends easily, but you will have to manually loop through
>> your friends records in order to get the "latest posts from friends"
>> or maybe I am missing something important here...
> You're not. But what's the big deal? What you're describing can be done with
> two requests (the second being a multi-key get for latest post of each
> friend). I doubt you'll run into many issues unless the friends list is
> enormous, and I'm sure a better approach could be found.

View raw message