8

これまで、私は常にリレーショナル データベースを使用してきました (そして、非常に満足しています!)。しかし、最近、Parseを発見し、非常に優れていると感じたので、試してみることにしました。ただし、NoSQL データベースが付属しています。私はまだそれを理解しようとしています。私の質問は、どのようにローカリゼーションを達成することをお勧めしますか? 以下の方法が考えられますが、いかがでしょうか。

  • アプローチ A: ドキュメントに単一の「文字列」フィールドを用意し、そのフィールドにすべての言語固有のデータを格納します。例えば、

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

  • アプローチ B: ドキュメントに複数のフィールドを用意し、各フィールドが 1 つの言語固有のファイルを指すようにします。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: (NEW) アプローチ B と同様に、すべての関連データを同じドキュメントに保持する目的で、2 つのドキュメントよりも多くの列を優先します。

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

アプローチ A: 理にかなっていますが、(Parse フレームワークで) 関連するデータのみをクライアントに送り返す簡単な方法がわかりません。すべての文字列をクライアントに送信します -> 冗長帯域幅の使用

アプローチ B: リレーショナル db のバックグラウンドから来て、列が多すぎる可能性は好きではありません (最終的には 30 の異なる言語に対して 30 の異なる列を持つことができます)。また、クライアントは単にオブジェクトを使用することはできません。文字列。フィールド名の最後に常に言語コードを追加する必要がありますが、これは面倒です (そして危険でもあります)。しかし、このアプローチは私にとって最も理にかなっています。

アプローチ C: 「NoSQL をリレーショナル データベース設計パラダイムに適応させるつもりなら、NoSQL のポイントは何ですか」と言っているのが聞こえます。

アプローチ D: はい、途方もなく多くの列が作成されますが、必要なすべてのデータを 1 つ以上のドキュメントに分散するのではなく、1 つのドキュメントに保持することが重要な目標であると感じました。また、フィールドの数はまったく問題ではありません。したがって、私は今このアプローチを採用しています。

では、NoSQL db スキーマでローカリゼーションを実現するにはどうすればよいでしょうか?

4

2 に答える 2

0

Ayende は、次のようなものを使用することを提案しました

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