8

直到现在，我一直在使用关系数据库（确实很开心！）。然而，最近，我发现了Parse，发现它非常好，所以决定试一试。但是，它带有一个 NoSQL 数据库。我仍在努力解决它。所以我的问题是，您如何建议实现本地化？我可以想到以下方法，你怎么看？

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

    "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：就像在关系数据库模式中一样，有一个带有语言代码的单独字符串表。单独查询此表/文档并合并结果

  • 方法 D：（新）与方法 B 类似，优先考虑多个列而不是两个文档，目的是将所有相关数据保存在同一个文档中。

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

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

方法 B：来自关系数据库背景，我不喜欢有太多列的前景（它最终可能有 30 种不同的列，用于 30 种不同的语言），而且客户端不能只使用对象。字符串。它总是必须在字段名称的末尾附加语言代码，这很乏味（也很危险）。但这种方法对我来说最有意义。

方法 C：我可以听到您说“如果您要使 NoSQL 适应关系数据库设计范式，那么 NoSQL 有什么意义”

方法 D：是的，你最终会得到很多可笑的列，但我觉得一个关键目标是将所有必要的数据保存在一个文档中，而不是将它们分布在 1 个以上的文档中。字段数量根本不是问题。因此，我现在采用这种方法。

那么，如何在 NoSQL 数据库模式中实现本地化？

4

2 回答 2

2

最近在 RavenDB 论坛上有一个关于这个主题的讨论。 看这里

像 NoSQL 中的大多数东西一样，有许多不同的选项。提出的一个想法是，在许多文档数据库（如 RavenDB）中，您可以拥有基于字符串的“语义”键。这些可以用来提供数据本地化。

例如，考虑多个文档一起工作来表示一个产品：

products/1
{
  "Price" : 10.00
{

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

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

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

不可本地化的属性存储在products/1其中是主文档键。但随后可本地化的字符串可以进入其他与其键相关的文档中。

为了使这项工作顺利进行 - 使用不同的文档会产生一些管理开销。在 RavenDB 中 - 这将由自定义“捆绑包”提供。（它还不存在——我正在研究它。）其他数据库可能有不同的实现细节，可能仍然允许这种方法可行。

于 2013-04-02T23:55:38.277 回答
0

Ayende 建议使用类似的东西

{
  "States": [
    {
      "Name": [
        {
          "Culture": "en",
           "Value": "Texas"
        },
        {
          "Culture": "fr", 
          "Value": "French Texas" 
        } ],
        "Abbrevation": "TX" 
    }]
}
于 2013-10-07T22:37:13.607 回答