How to achieve localisation with NoSQL

Question

Until now, I've always used relational databases (and was quite happy indeed!). However, recently, I discovered Parse and found it quite nice so decided to give it a try. However, it comes with a NoSQL database. I am still trying to get my head around it. So my question is, how would you recommend achieving localisation? I could think of the following approaches, what do you think?

• Approach A: Have a single 'strings' field on the document and store all language specific data in that field. For example,

  "strings":
  {
    "en" : 
      {
        "title" : "English title"
      }
    "de" :
      {
        "title" : "Deutsch Titel"
      }
  }
  

• Approach B: Have multiple fields on the document, each field pointing to one language specific file. An define another document named strings. For example,

  "strings_en": <Pointer to a *strings* object>
  "strings_de": <Pointer to a *strings* object>
  
  // And here's one *strings* document
  {
    "title" : "My English title"
  }
  

• Approach C: Just as in a relational database schema, have a separate strings table with language code. Query this table/document separately and merge results

• Approach D: (NEW) Similar to Approach B, favouring many columns over two documents with the aim of keeping all relevant data in the same document.

  {
    "title_en" : "English title",
    "title_de" : "Deutsch titel",
    "description_en" : "English description",
    "description_de" : "Deutsch beschreibung"
  }
  

Approach A: Makes sense to me, but I don't know an easy way (in Parse framework) to send back only the relevant data to the client. It will send all strings to the client -> redundant bandwidth use

Approach B: Coming from a relational db background, I don't like the prospect of having too many columns (it can eventually have 30 different columns for 30 different languages) and also, the client can't just use object.strings. It always has to append the language code at the end of the field name, which is tedious (and risky too). But this approach makes most sense to me.

Approach C: I can hear you saying 'What's the point of NoSQL if you're going to adapt NoSQL to relational db design paradigm'

Approach D: Yes, you will end up with ridiculously many columns but I felt a key goal is to keep all necessary data in one document as opposed to distributing them over 1+ documents. And number of fields is not a problem at all. Hence, I'm going with this approach now.

So, how do you achieve localisation in your NoSQL db schemas?

Answer 1

There was a discussion on the RavenDB forums about this very topic recently. See Here

Like most things in NoSQL, there are many different options. One idea that came up is that in many document databases (like RavenDB), you can have string-based "semantic" keys. These could be exploited to provide data localization.

For example, consider multiple documents working together to represent a product:

products/1
{
  "Price" : 10.00
{

products/1/en
{
  "Name" : "ball"
}

products/1/es
{
  "Name" : "bola"
}

products/1/fr
{
  "Name" : "balle"
}

The non-localizable properties are stored in products/1 which is the main document key. But then localizable strings could go in other documents that are related by their key.

To make this work well - there is some management overhead of working with the different documents. In RavenDB - this would be provided by a custom "bundle". (It doesn't exist yet - I am working on it.) Other databases may have different implementation details that might still allow this approach to be viable.

Answer 2

Ayende suggested to use somehting like

{
  "States": [
    {
      "Name": [
        {
          "Culture": "en",
           "Value": "Texas"
        },
        {
          "Culture": "fr", 
          "Value": "French Texas" 
        } ],
        "Abbrevation": "TX" 
    }]
}