Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D0A4597EF for ; Thu, 10 May 2012 05:49:38 +0000 (UTC) Received: (qmail 1477 invoked by uid 500); 10 May 2012 05:49:37 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 671 invoked by uid 500); 10 May 2012 05:49:34 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 641 invoked by uid 99); 10 May 2012 05:49:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 May 2012 05:49:33 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jens@couchbase.com designates 206.225.164.30 as permitted sender) Received: from [206.225.164.30] (HELO EXHUB020-3.exch020.serverdata.net) (206.225.164.30) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 May 2012 05:49:28 +0000 Received: from EXVMBX020-1.exch020.serverdata.net ([169.254.4.3]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Wed, 9 May 2012 22:49:06 -0700 From: Jens Alfke To: "user@couchdb.apache.org" Date: Wed, 9 May 2012 22:49:04 -0700 Subject: Re: include_docs with _all_docs Thread-Topic: include_docs with _all_docs Thread-Index: Ac0ucJv99C5hnidPSc22rAW3rt+ePQ== Message-ID: <5F35AD14-525A-486F-8708-B7F2D4F8343F@couchbase.com> References: <7caa2578e04507ec25f97df01e5d66ab.squirrel@secure61.inmotionhosting.com> <2ba5948b99a136aebad13e1cfcd8b525.squirrel@secure61.inmotionhosting.com> <7CC02CFB-C515-478C-813C-274859EE5D4B@couchbase.com> <3c42307e64dc9ecee1b595858e3b81fe.squirrel@secure61.inmotionhosting.com> In-Reply-To: <3c42307e64dc9ecee1b595858e3b81fe.squirrel@secure61.inmotionhosting.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5F35AD14525A486F8708B7F2D4F8343Fcouchbasecom_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_5F35AD14525A486F8708B7F2D4F8343Fcouchbasecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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=92t need to be part of t= he database, and I don=92t think there=92s 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=92ve come to the wrong place =97 that= =92s exactly what NoSQL is *not* about. It=92s sort of like a C++ developer= wandering into a JavaScript conference and asking people how they enforce = type-safety, constness and member access privileges. =97Jens --_000_5F35AD14525A486F8708B7F2D4F8343Fcouchbasecom_--