couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <>
Subject Re: include_docs with _all_docs
Date Thu, 10 May 2012 05:49:04 GMT

On May 9, 2012, at 2:53 PM, <<>>
<<>> wrote:

1. I'm in data management. There is a strong business case for having
robust business descriptions for each column (where it came from, what it
means, who entered it, how it's calculated...etc). Risk officers need to
analyze what data is in a db that (aka after a developer builds the
database and moves on nobody will know what attributes exist--without
reverse engineering the application).

That sounds like documentation. I strongly agree that data formats/schemas should be documented,
but that documentation doesn’t need to be part of the database, and I don’t think there’s
any really good place to put it in a schemaless storage system like CouchDB.

In general, if you want highly structured data that rigidly and enforceably follows a predefined
structure, you’ve come to the wrong place — that’s exactly what NoSQL is *not* about.
It’s sort of like a C++ developer wandering into a JavaScript conference and asking people
how they enforce type-safety, constness and member access privileges.


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