> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected] >> > >> >> 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 <[email protected]> >> 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 >
