Hmm, I wouldn't use a foreign key for tags in Postgres either, just some
kind of list (json or I believe there's something else too.)


Thanks for your help,
Ram.

On Sat, Jun 13, 2015 at 2:13 PM, Johannes Jörg Schmidt <[email protected]
> wrote:

> Hi Ram,
>
> translations and tags are good examples where I would not use a
> relationship in CouchDB in most cases but instead include them in an object
> or array instead.
> But maybe that's what you would do with PostgreSQL anyway, since it
> supports JSON natively?
> Am 13.06.2015 12:23 schrieb "Ram Rachum" <[email protected]>:
>
> Thanks Aurélien!
>
> Can you please give me an example of a case where you'd use a relationship
> in PostgreSQL, but wouldn't if you were using CouchDB? This might help me
> understand the approach. (I tried reading about it but couldn't
> understand.)
>
>
> Thanks,
> Ram.
>
>
> On Sat, Jun 13, 2015 at 12:39 PM, Aurélien Bénel <[email protected]>
> wrote:
>
> > >>>
> > http://docs.ehealthafrica.org/couchdb-best-practices/#one-to-n-relations
> > >> Is this how I'm supposed to use CouchDB? Because isn't this
> relational?
> > I think that if I'm pushing CouchDB to be like PostgreSQL, then maybe I'm
> > doing it wrong and I should either use PostgreSQL idiomatically or
> CouchDB
> > idiomatically.
> > >
> > > The fact that CouchDB is a document based database does not mean you
> > cannot model relations with it when it makes sense.
> >
> > Ram, Johannes, I'm afraid there is a term confusion between "relations"
> > and "relationships".
> >
> > The "relation" of "relational databases" is an algebraic notion for
> > something you would probably call a "table" (see
> > https://en.wikipedia.org/wiki/Relational_algebra).
> >
> > Having no "relations" (aka tables) doesn't mean you don't have
> > "relationships" (even if you have probably less of them).
> >
> >
> > Regards,
> >
> > Aurélien
>

Reply via email to