couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hahn <m...@boutiquing.com>
Subject Re: RESTful document structure
Date Sun, 10 Jul 2011 20:11:14 GMT
> 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.

Oh well.  It is what it is.

On Sun, Jul 10, 2011 at 1:02 AM, Keith Gable <ziggy@ignition-project.com> wrote:
> It's probably a bad idea to mix different applications on the same database
> unless they're related in some way. It's OK to mix different applications on
> the same CouchDB instance.
>
> I somehow think you are equating database to CouchDB instance rather than
> database = document collection running on a CouchDB instance. Design
> documents exist for the same reason that there are classes in OO languages.
> Sure, 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.
>
> On Sat, Jul 9, 2011 at 11:46 PM, Mark Hahn <mark@boutiquing.com> wrote:
>
>> Thanks.  I think I understand now.  Multiple apps can coexists on one
>> database and you don't want code from different apps mixed together.
>> I've never considered that since I've always had one app, one db.
>> Also I always thought of the views as part of the db, not part of the
>> app.  In something like mysql the indexes are definitely part of the
>> db.
>>
>> Now I can sleep at night.
>>
>> On Sat, Jul 9, 2011 at 9:26 PM, Christian Carter <cdcarter@gmail.com>
>> wrote:
>> >>
>> >> >  It makes sense
>> >>
>> >> I've asked this same question several times in several ways. The
>> >> answer I've always gotten was that it was logical or made sense.
>> >> Apparently there is no actual purpose for designs.  I know it doesn't
>> >> matter but for some reason it bugs me.
>> >>
>> >
>> > Well, they let you totally self-contain an application, which is super
>> handy
>> > for the couchapp users on the list.  But the main feature is that they
>> make
>> > sense.  You can logically group together things that go together, which
>> can
>> > lead to nice reusable and replicator friendly components.
>> >
>> > Christian Carter
>> >
>> >
>> >
>> >>
>> >> On Sat, Jul 9, 2011 at 6:13 PM, Keith Gable <ziggy@ignition-project.com
>> >
>> >> wrote:
>> >> > I can't really answer your question directly, but I will say that I
>> have
>> >> one
>> >> > design doc for every type (or OO class) of document I have. It makes
>> >> sense
>> >> > when mating CouchDB with a object oriented language (Ruby in my case),
>> >> but
>> >> > YMMV.
>> >> >
>> >> > On Sat, Jul 9, 2011 at 6:59 PM, Mark Hahn <mark@boutiquing.com>
>> wrote:
>> >> >
>> >> >> 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?
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Keith Gable
>> >> > A+ Certified Professional
>> >> > Network+ Certified Professional
>> >> > Web Developer
>> >> >
>> >>
>> >
>>
>
>
>
> --
> Keith Gable
> A+ Certified Professional
> Network+ Certified Professional
> Web Developer
>

Mime
View raw message