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.
