incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Carlson <lancecarl...@gmail.com>
Subject Re: Trying to wrap my head around CouchDB
Date Tue, 16 Jul 2013 22:55:35 GMT
When establishing relationships between documents, it's perfectly
reasonable to specify a relationship_id key inside of the document and
storing the _id of another document in there. Keep in mind that it usually
takes 2 queries to get the information you want. You can also use view
collation to stick it all in one query, but sometimes this can get hairy.

Sometimes it also makes sense to just embed other docs within your doc for
performance reasons. It really depends on your use case...

For the most part, I try to keep it simple and discourage a lot of nesting.
The more nesting you have, the harder it is to export the data into
something that is "table-esk" like CSV.


On Tue, Jul 16, 2013 at 6:42 PM, Lance Carlson <lancecarlson@gmail.com>wrote:

> I've also found when I've needed to  create large filtering engines
> with searching that Couchdb views fall short. I would recommend using
> cloudant's search API or elastic search for this use case so you don't
> start thinking Couchdb sucks :)
>
> Sent from my iPhone
>
> On Jul 16, 2013, at 6:35 PM, "Yves S. Garret"
> <yoursurrogategod@gmail.com> wrote:
>
> > On Tue, Jul 16, 2013 at 6:06 PM, Oliver Schmidt
> > <spiollinux@googlemail.com>wrote:
> >
> >>
> >>> Ok.  Say in MySQL I have an orders table, a customers table and an
> >> items
> >>> table (where the stuff that I want to sell is located).  How would this
> >>> look like
> >>> in CouchDB?
> >> You put each customer, order and item into its own document.
> >>
> >>> So you would have each customer, order and items document, but how
> >> would
> >>> you differentiate between the 3 types of documents?
> >> A common way to do that is to give each document a "type" attribute and
> >> then check for certain types in the views.
> >> The guide is quite outdated, nevertheless the first chapters are very
> >> informative, good to read and still correct.
> >>
> >>> I realize that this is not the same as MySQL, but I'm trying to find
> the
> >>> relationships
> >>> (and model them in my head) as to how I could do the same thing in
> >> CouchDB.
> >> Maybe you need some time to "unlearn" these SQL things. I find CouchDBs
> >> way of handling documents intuitive, maybe because I never really
> learned
> >> SQL ;)
> >
> > It seems that way :) .  The very first OS that I used was MySQL, it was
> > open source and
> > relatively easy to setup, so I gave it a shot.
>

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