couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Stott <>
Subject Re: In regards to naming of design documents
Date Wed, 11 Nov 2009 00:57:22 GMT
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?

On Tue, Nov 10, 2009 at 6:06 PM, Chris Stockton

> Hello,
> We are deciding our convention for how we will emulate tables in couch
> db. Our current idea is the user named tables will each have a design
> document with punycode names. "table┼łame" is a design doc stored as ->
> I.E. _design/tableame-uqb. Of course this brings up a collision
> problem for our system defined design docs, such as lucene etc. So it
> was decided system design docs would begin with _ and user tables
> would be prohibited from beginning with _. However this gives a uneasy
> feeling as _ is very much reserved as a first character in both
> properties and database names, although as of .10 _design/_foo is
> allowed, I would like to make sure this is considered acceptable
> practice and will remain available moving forward.
> Some thoughts have been a design document specifying the tables within
> the database, like _design/tables, this seems like a fairly clean
> approach and I am unsure any advantage is given by having separate
> design docs for each table as they contain no views (currently those
> live in a separate design doc) just meta data about the table. I would
> appreciate hearing any solutions people have made to this problem
> (user created tables in a database).
> -Chris

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