Jeans, 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 <[email protected]> wrote: On May 9, 2012, at 2:53 PM, <[email protected]<mailto:[email protected]>> <[email protected]<mailto:[email protected]>> 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. —Jens
