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 <[email protected]> wrote: > interesting write-up on the pitfalls the diaspora project faced down with > mongodb > http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-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*
