couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: include_docs with _all_docs
Date Thu, 10 May 2012 06:58:59 GMT
1. You believe in documentation but not in the database? So should I assume you'd put it in
a text file or Word doc outside the DB? If so it will get out of sync over time and as a programmer
you don't want to spend time keeping that doc up to date so like my thread with Mark, a report
of what attributes exist is self maintaining if based in the DB.

In terms of what NoSQL is or isn't let's see what the community thinks, and what the industry
buys. I forecast that enterprises will only adopt NoSQL dbs that support enterprise class
needs including metadata and compliance.
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Jens Alfke <> wrote:

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