>方法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种不同的列),而且,客户端不能只使用object.strings.它总是必须在字段名称的末尾附加语言代码,这是繁琐的(也有风险).但这种方法对我来说最有意义.
方法C：我可以听到你说’如果你要将Nosql改编为关系数据库设计范例,Nosql有什么意义’
方法D：是的,你最终会得到可笑的许多专栏,但我觉得一个关键的目标是将所有必要的数据保存在一个文档中,而不是将它们分配到1个文档中.并且字段数根本不是问题.因此,我现在正采用这种方法.
像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中 – 这将由自定义“捆绑”提供. (它还不存在 – 我正在研究它.)其他数据库可能有不同的实现细节,可能仍然允许这种方法可行.