In that case, if you say that by definition all docs in one app are related, then there should be one database, but different design docs for performance.
What is the utility of having multiple views in one design doc, other than being able to edit them in one place? Or another way to phrase the same question: why do design docs exist? On Sat, Jul 9, 2011 at 1:44 PM, Robert Newson <[email protected]> wrote: > That's not quite accurate. All views inside the same design document > are written to the same file and so we update them all at once, but > each design document can build its views independently. The pivot > point for view build parallelism is the design document, not the > database. > > Keeping unrelated documents in different databases is just another way > of saying keep related documents in the same database, which is sane. > > B. > > On 9 July 2011 21:37, Mark Hahn <[email protected]> wrote: >> However, the more views, designs, etc. you put in a single db the >> slower some operations, like updating a view, get. I tend to use >> different DBs when I know the data has no inter-connections and has no >> reason to be combined. It also feels good to have independent dbs >> when used by independent modules. >> >> The only negative I can think of is having more dbs to manage in >> operations like replication, but that is just bookkeeping. >> >> On Sat, Jul 9, 2011 at 1:29 PM, Robert Newson <[email protected]> wrote: >>> In CouchDB, most of the important features are scoped at the database >>> level. For example, views, replication, validation functions, rewrite >>> rules and _security objects. Separating data into different databases >>> by type would remove access to almost all the compelling features of >>> CouchDB, reducing it to a mere document store, not a document >>> database. >>> >>> B. >>> >>> On 9 July 2011 21:19, Keith Gable <[email protected]> wrote: >>>> REST is more concerned with verbs and resources and what happens when you >>>> combine the two. >>>> >>>> The OP is more than welcome to use different databases for each distinct >>>> type of data, however it makes it more difficult to do stuff and is >>>> certainly not necessary. >>>> >>>> If you think about a CouchDB document as a resource within a collection >>>> that >>>> is your database, it makes sense. VERB /database-collection/document. >>>> Perfectly RESTful to me. >>>> >>>> On Sat, Jul 9, 2011 at 2:35 PM, Robert Newson <[email protected]> wrote: >>>> >>>>> REST does not require that you use only one type of document per >>>>> database. Even if it did, I'd strongly advise violating a rule as >>>>> silly as that. >>>>> >>>>> Put whatever documents into your database as you please. >>>>> >>>>> B. >>>>> >>>>> On 9 July 2011 19:39, Johnny Weng Luu <[email protected]> wrote: >>>>> > Since CouchDB is implementing a RESTful API, doesn't that mean I wanna >>>>> put >>>>> > all documents of the same type in their own database? >>>>> > >>>>> > eg. >>>>> > >>>>> > POST http://localhost/users >>>>> > GET http://localhost/users/1 >>>>> > PUT http://localhost/users/1 >>>>> > DELETE http://localhost/users/1 >>>>> > >>>>> > POST http://localhost/threads >>>>> > GET http://localhost/threads/1 >>>>> > PUT http://localhost/threads/1 >>>>> > DELETE http://localhost/threads/1 >>>>> > >>>>> > Rather than putting them all in one big database ( >>>>> http://localhost/my_app). >>>>> > >>>>> > Doesn't a 100% RESTful approach mean that the former is more correct? >>>>> > >>>>> >>>> >>>> >>>> >>>> -- >>>> Keith Gable >>>> A+ Certified Professional >>>> Network+ Certified Professional >>>> Web Developer >>>> >>> >> >
