incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Der Engel <engels...@gmail.com>
Subject Re: Would this be a sane use case for couchdb?
Date Thu, 10 Apr 2014 05:01:35 GMT
How about databases vs documents? for example, retaking the address card
web app where each user has its own list of address cards, should each user
have its own database or should all the address cards(documents) of all
users be placed in a single database? What are the benefits/drawbacks of
doing one over the other?


On Wed, Apr 9, 2014 at 10:54 PM, Jens Alfke <jens@couchbase.com> wrote:

>
> On Apr 9, 2014, at 5:45 PM, Der Engel <engelster@gmail.com> wrote:
>
> > if understand you correctly, each user should have only one
> > document for their list of address cards? or one document per address
> card?
>
> One document per card. But you _could_ do it either way; it’s one of those
> things where it may take a bit of experience to be able to intuit the right
> “grain size” for a document.
>
> The problems with making documents too big are —
> * Structure gets more complicated
> * Takes more time/bandwidth/memory to load or save it (you can’t load
> partial docs)
> * If two users modify the same doc at once you can end up with conflicts
> or errors
> * You can’t easily refer to an item within a document from another
> document, i.e. it doesn’t have its own ID or URL.
> If you think of the extreme case, where you put everything in one
> document, you might as well not use a database at all but just store it in
> a file :) Which is do-able, but the drawbacks are pretty obvious.
>
> So it’s not something where if you make the wrong decision it just Doesn’t
> Work and you’re stuck. Rather, you’ll just find the code getting awkward or
> performance getting slower than you like, and then you can think about
> refactoring. (CouchDB is really forgiving about refactoring your data
> model. It’s much easier than it is in SQL, for instance.)
>
> > What about if in the future, users want to add more information about
> their
> > contacts? like their favorite books (with price, author, title) for each
> > contact, should all of these still be in the same document?
>
> You could do that. I’m not sure what the best choice would be.
> If not, you’d create a separate document and one of its properties would
> be the ID of the main address card document.
>
> > For example, in my case, invoicing software, users are
> > going to create hundreds invoices every year, so keeping all the invoices
> > on a single document is going to make the document big overtime, is that
> > normal?
>
> Yeah, you wouldn’t put those in a single document. Probably one per
> invoice.
>
> —Jens
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message