On Thu, May 10, 2012 at 3:48 PM, bryan rasmussen <[email protected]>wrote:
> 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, [email protected] > <[email protected]> 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 function? > > -- > > 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 > > > -- -- Andrew Melo
