couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Melo <>
Subject Re: include_docs with _all_docs
Date Thu, 10 May 2012 08:06:59 GMT
On Thu, May 10, 2012 at 3:48 PM, bryan rasmussen

> I suggest that enterprise usage isn't the primary use case for
> couchdb. Or at least not for that kind of enterprise data analysis.
> Cheers,
> Bryan Rasmussen
> On Thu, May 10, 2012 at 8:58 AM,
> <> wrote:
> > 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.

You have to do it both ways "somewhere", even if you're using a traditional
database. If automation to enforce a convention is what you want (i.e. to
keep things from getting out of sync), you can provide it with a _validate
function. CouchDB doesn't care about what javascript blobs you're passing
in. It does, however, provide you the tools to enforce whatever conventions
you want.

> >
> > 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.

Am I understanding correctly that "metadata" to you is just the list of
keys in the top-level json document? If so, wouldn't the developer
"checking in" a new attribute map to modifying a design document, and
wouldn't then enforcement of your desired schema be with a _validate

> > --
> > Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> >
> > Jens Alfke <> wrote:
> >
> >
> > On May 9, 2012, at 2:53 PM, <<mailto:
>>> <<mailto:
>>> 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
> >

Andrew Melo

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