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.