会話システムの設計にDocumentDbを使用する場合、関連するすべての関係者の会話の詳細を繰り返すのは良い考えですか？Azure DocumentDBのコレクション間で同じデータを繰り返す
シャーディングは、ユーザー名の最初のアルファベットを使用して実装されています。ユーザAはF、I、Zにメッセージを送信します。これらのユーザは（シャーディングのため）異なるコレクションの一部であるため、メッセージの詳細は各コレクションで繰り返されます。このデザインは速い読みに役立ちます（履歴を表示するために1つの場所に移動する必要があるので速くなります）。しかし、私が複数の場所に書き込む必要があるので、執筆は面倒かもしれません。
私の質問は、DocumentDbを使用してそのようなシステムを構築するときに、詳細を繰り返すことができますか？または、詳細については集中コレクションを作成し、各ユーザーコレクションのid部分を維持することをお勧めしますか？
助けてください。
ありがとう、 Soma。
完全に正規化されたデータモデリングと部分的に非正規化されたデータモデリングの間のトレードオフに似ていますが、これはコレクションの問題が異なるため完全なフィットではありません。つまり、私は、この場合、非正規化に関する答えは「それは依存している」と考えています。
あなたは、読みやすくすることを指摘して正しい言葉を考えています。
しかし、私のアドバイスは、完全に正規化されたものが十分に速くないことと、正規化されていないものがより高速であるという証拠がない限り、非正規化しないことです。すべての非正規化はデータ破損のリスクを増加させ、このようなバグを解決することは非常に難しいことです。あなたは1か所に保管しようとしましたか？それは十分速いですか？あなたはこの非正規化がより速いと思う実験をしましたか？
また、私はこの場合のパフォーマンスに関して反対の本能を持っています。 2つのクエリを発行して1つのクエリとは異なるコレクションにヒットしなければならない場合は、スループットが上がり、組み合わせた操作の遅延が小さくなることが予想されます。
私はあなたがユーザーのパーティションを作っているようですが、これは代わりに会話でIDをパーティション化するのに適したケースですか？その後、userIdの会話を追跡することができます。会話IDを取得するために余分な呼び出しが必要ですが、いったん設定する必要があります。
ありがとうございました。現在も様々な選択肢を試しています。 1つのアイデアに着手する前にいくつかのテストを実行します。 –
Cool。答えを受け入れることができますか？ –
DRYがコードにしかないということは、データにも適用されます。標準的な定義を引用するには：「知識のすべての部分は、システム内で単一の、明確で信頼できる表現を持たなければなりません。それは、コピーがオリジナルであるかのようにシステムが決して扱わないことを知っている限り、情報のコピーが非常に有用である（例えばキャッシュするとき）時があるということである。 – neuronaut