On Fri, Mar 20, 2009 at 12:10:17PM +0100, Zoltan Lajos Kis wrote:
> done nicely with CouchDB. Currently in my relational database model I  
> follow the convention that my "objects" reference property tables, and  
> also property_translation tables
> reference the property tables. A silly example:
>
> Person table
> ---------------------
> name | eye_color_id
> ==============
> Zoltan|blue_id
> ...
> ---------------------
>
> Color table
> ---------------------
> color_id|rgb_code
> ==============
> blue_id|#0000ff
> ...
> ---------------------
>
> Color translation table
> ----------------------
> color_id|lang|name
> ==============
> blue_id|en|"blue"
> blue_id|hu|"kék"
> ----------------------

Since CouchDB objects aren't just rows, you could keep everything to do with
'blue' in a single document:

{
  "_id": "ab84376da4090f23",
  "type": "colour",
  "rgb_code": "#0000ff",
  "translations": {
    "en":"blue",
    "hu":"kék"
  }
}

Of course when you render a person, you still need to fetch the associated
colour document. This means two fetches, although you can do some caching
client-side of the colour docs (or just rely on HTTP caching via etags - you
may still get a HTTP exchange but with an empty body)

Instead of having a "type" field, you could instead embed this information
into the docid:

{
  "_id": "colour#ab84376da4090f23",
  ... etc
}

It's a matter of preference. It makes it easier to identify all colour
documents from futon or the all_docs view, without having to go via a custom
view on type. But views become a little more complex, as your map function
has to split the doc_id to determine which docs to include in a particular
view.

HTH,

Brian.