Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CABvT1DHBizEMrKv+EEdvW2PR-5dGcmr6f4X8DBAPbKg79MU_EA@mail.gmail.com>
References: 
 <CAFv3AGY1-Verp3Gr3gxEfchK5b08KghDzJJPHOcw5ijTP=8Saw@mail.gmail.com>
 <CABvT1DGCZ_P7h-BjcSM6GOiKDBSryVWD94-3fRrV1dc7rHWaDA@mail.gmail.com>
 <CAC7vo1BgV+nbsuxiXyWAkJ4=bt1XaD864-N-wh3D9zYSnpdZ7A@mail.gmail.com>
 <CABvT1DEbykS7utK9r-R5U+VcpsqxXbGbEBnK1TUs27NN110E3Q@mail.gmail.com>
 <CACXzkS_U5VHwtum2LjsstEwNz4e0hhv0jN_vkGTzoHnnq2MmkQ@mail.gmail.com>
 <CABvT1DHBizEMrKv+EEdvW2PR-5dGcmr6f4X8DBAPbKg79MU_EA@mail.gmail.com>
From: Mark Hahn <mark@boutiquing.com>
Date: Sat, 9 Jul 2011 16:59:51 -0700
Message-ID: 
 <CACXzkS_J1-U0X=Fd4ShPiWyXwL6j1r0w8cjxR2KCZWzGTH5QiA@mail.gmail.com>
Subject: Re: RESTful document structure
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <rnewson@apache.org> 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 <mark@boutiquing.com> wrote:
>> However, the more views, designs, etc. you put in a single db the
>> slower some operations, like updating a view, get. =A0I tend to use
>> different DBs when I know the data has no inter-connections and has no
>> reason to be combined. =A0It 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 <rnewson@apache.org> 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 <ziggy@ignition-project.com> 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 distin=
ct
>>>> 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 collectio=
n 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 <rnewson@apache.org> wro=
te:
>>>>
>>>>> 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 <johnny.weng.luu@gmail.com> wro=
te:
>>>>> > Since CouchDB is implementing a RESTful API, doesn't that mean I wa=
nna
>>>>> 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 correc=
t?
>>>>> >
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Keith Gable
>>>> A+ Certified Professional
>>>> Network+ Certified Professional
>>>> Web Developer
>>>>
>>>
>>
>