incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: why you should never use X
Date Tue, 12 Nov 2013 19:01:06 GMT
Actually, he is right: for serious, big and production apps you will
found yourself designing data schema for stored data. This isn't
problems for CouchDB since there is validate_doc_update functions that
will prevent you having broken documents, but this is for MongoDB. The
main profit of such schema that it defines the lower bound of the
required document fields, not the upper one as for relation databases
in their canonical design (e.g. without EAV tables).

Also you have to keep in mind that if you setup "implicit" relations
between documents you should except to find some data inconsistent:
comments without post, TV show data without seasons etc. E.g. orphan
documents are OK even if your business logic doesn't assume them.


On Tue, Nov 12, 2013 at 10:19 PM, matt j. sorenson
<> wrote:
> interesting write-up on the pitfalls the diaspora project faced down with
> mongodb
> I've seen a few "what's your use case" or "what use cases is couchdb good
> for" threads on the list, and I'd be curious what the top couchdb minds
> have to say about Sarah's assertions, social data and these 'undirected
> graphs'.
> Sarah actually seems to come to this harsh conclusion [about json document
> storage?]:
> MongoDB’s ideal use case is even narrower than our television data. The
> *only* thing it’s good at is storing arbitrary pieces of JSON. “Arbitrary,”
> in this context, means that you don’t care *at all* what’s inside that
> JSON. You don’t even look. There is no schema, not even an implicit schema,
> as there was in our TV show data. Each document is just a blob whose
> interior you make absolutely no assumptions about.
> which seems a little extreme to me =/
> --
> *matt j. sorenson*

View raw message