couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Stockton <>
Subject Re: In regards to naming of design documents
Date Thu, 12 Nov 2009 20:35:46 GMT

Thank you for your responses,

On Tue, Nov 10, 2009 at 5:57 PM, Nathan Stott <> wrote:
> I don't have an answer to your question; however, I have a question.  Why
> are you using couchdb to try to simulate tables?  Why not just use a RDBMS?
Our decisions to use couch took into account it's lack of constraints
seen in a RDBMS, which is why for 90% of our purpose it fits so well
into our design. I would be happy to explain the reasoning behind the
design decisions for some of the problems we are solving, and why
couch is the solution offline if you would like.

On Wed, Nov 11, 2009 at 1:18 AM, Brian Candler <> wrote:
> Possible solution: if your emulation layer is called "tablefoo", then have
> _design/tablefoo_<tablename> or _design/tfuser_<tablename>
We were thinking of doing something like this, might be a best-approach.

> Remember you don't *have* to have separate design docs per table - you can
> have multiple views within the same design doc, and the user doc will only
> be serialized once to the view server to build all those views.
Part of the design (which I left out in the previous mail) is we will
be dynamically creating views fairly often, placing them into the
tables design document. I would like to have a single design document
with all views for a database, as well as the lookup for the tables.
However from my understanding when we added/updated views for a design
doc, it would cause the other views under that design document to also
re-index. I could see on a large database with 100+ tables, having to
re-index every view for all tables for a single view update could get
expensive. I would appreciate you to kindly correct me if I am wrong
as that would perhaps sway our design decisions.



View raw message