You're obviously free to do whatever you want, but I'd have it split like
so:
design doc 1: documents that are users
design doc 2: documents that are requests
design doc 3: documents that are service providing users (or have
user.service_provider = true)
Or put another way, consider views to be methods and design docs to be
classes. Request.by_priority, Request.by_user(startkey=[userid, 0],
endkey=[userid, {}]), etc.
Since you can have as many design docs as you want and there's a performance
improvement (at the cost of disk space) of having multiple design docs, why
not do it this way?
On Mon, Jul 11, 2011 at 9:41 AM, Kevin R. Coombes <[email protected]
> wrote:
> 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.
>>
>>
--
Keith Gable
A+ Certified Professional
Network+ Certified Professional
Web Developer
