如何使用NoSQL实现本地化 [英] How to achieve localisation with NoSQL

问题描述

直到现在，我一直使用关系数据库(确实很高兴！).但是，最近，我发现了解析并发现它很好，因此决定尝试一下.但是，它带有NoSQL数据库.我仍在努力解决这个问题.所以我的问题是，您如何建议实现本地化?我可以想到以下方法，您怎么看?

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?

• 方法A:在文档上有一个字符串"字段，并将所有特定于语言的数据存储在该字段中.例如，

• 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"
    }
}

方法B:文档上有多个字段，每个字段指向一个语言特定的文件.定义另一个名为 strings 的文档.例如，

"strings_en": <Pointer to a *strings* object>
"strings_de": <Pointer to a *strings* object>

// And here's one *strings* document
{
  "title" : "My English title"
}

方法C:就像在关系数据库架构中一样，有一个单独的带有语言代码的 strings 表.分别查询这个表/文档并合并结果

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

方法D :(新)类似于方法B，在两个文档中增加了许多列，目的是将所有相关数据保留在同一文档中.

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"
}

方法A:对我来说很有意义，但是我不知道一种简单的方法(在Parse框架中)仅将相关数据发送回客户端.它将所有字符串发送到客户端->使用冗余带宽

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

方法B:来自关系数据库的背景，我不希望有太多的列(它最终可能会为30种不同的语言提供30个不同的列)，而且客户不能只使用对象.字符串.它总是必须在字段名称的末尾附加语言代码，这很乏味(也很冒险).但是这种方法对我来说最有意义.

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.

方法C:我听到你说'如果要使NoSQL适应关系数据库设计范例，NoSQL有什么意义?

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'

方法D:是的，您最终将获得很多列，但我觉得一个主要目标是将所有必要的数据保留在一个文档中，而不是将它们分发给1个以上的文档.字段数量根本不是问题.因此，我现在要采用这种方法.

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.

那么，如何在NoSQL db模式中实现本地化?

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

推荐答案

RavenDB论坛上最近对此话题进行了讨论.在此处查看

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

与 NoSQL 中的大多数内容一样，有许多不同的选项.出现的一个想法是，在许多文档数据库(如RavenDB)中，您可以具有基于字符串的语义"键.这些可以被利用来提供数据本地化.

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"
}

不可本地化的属性存储在主文档密钥 products/1 中.但是，然后可本地化的字符串可以放入与它们的键相关的其他文档中.

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.

为使此工作顺利进行-使用不同的文档会产生一些管理开销.在RavenDB中-这将由一个自定义的捆绑包"提供.(它尚不存在-我正在研究它.)其他数据库可能具有不同的实现细节，可能仍使该方法可行.

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.

这篇关于如何使用NoSQL实现本地化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！