I like the idea that "views are methods and design docs are classes".
I'm just not convinced that "classes" has to map directly to
classes/subsets of documents.
Both classes of people who use the system (requesters and service
providers) deal with the same set of documents: requests. And the vast
majority of documents in the database will be requests. What differs is
the set of actions/methods that different classes of people can or
should perform with those documents. So I still think that splitting
the design docs to match the main classes of people who interact with
the system (with the views as their methods) is a reasonable way to do
things....
Kevin
On 7/11/2011 9:52 AM, Keith Gable wrote:
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.
