couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin R. Coombes" <kevin.r.coom...@gmail.com>
Subject Re: RESTful document structure
Date Mon, 11 Jul 2011 14:41:30 GMT
Having just started putting together a db where multiple design docs 
make sense (at least to me), I can perhaps offer an explanation. We are 
trying to use couch to track a certain class of service requests.

Design doc 1:  All users can make requests, and they can see the status 
of their requests.

Design doc 2: Only the people who actually provide service can look at 
the full queue and decide whether to accept a request (by assigning it 
to someone responsible for fulfilling the request) or declining a 
request (with an explanation).

The basic views/interfaces used by the two groups of people are 
different, so it is actually easiest if the code is separated into 
differenty design documents.  Since we also tend to implement security 
through a proxy layer, it is also convenient to have a different class 
of URLs that can bre controlled by the proxy server, and the design docs 
make this easy:
     /ourdb/_design/users
is separate from
     /ourdb/_design/workers
and so we can put separate controls on who can access them.

There is also a third design doc for administrators who can generate 
reports on how many requests have been received, how many have been 
acted on, etc. in any given time frame.

To me, these do not represent separate apps...

     -- Kevin

On 7/10/2011 3:11 PM, Mark Hahn wrote:
>> you could make one single class (ClassToRuleThemAll, let's say) to
> hold the data for every single data type you work with, but that's silly.
>
> It's silly because there is a practical disadvantage in that every
> instance would waste space for all the variables that would be needed.
>
> I can't think of any practical advantage for having multiple design
> docs unless multiple apps share a db.
>

Mime
View raw message