複数のエンティティを同じコンテナーにまとめる
eコマース アプリケーション用のデータベースのモデル化はほぼ完了しました。 次の概念を示すために、販売注文エンティティを見てみましょう。
販売注文エンティティをモデル化する
他のエンティティと同様に、操作を確認してから、関連データを埋め込むか参照するかを決定します。 このシナリオでは、販売注文の詳細が埋め込みに最適な候補になります。 これは、注文に含まれる項目に制限がなく、データは常に一緒に挿入され、読み込まれるからです。 そのため、販売注文エンティティ内の配列として、販売注文の詳細を埋め込みます。 また、salesOrder という名前の新しいコンテナーにデータを格納します。
次に、パーティション キーを選択します。 販売注文の検索は常に顧客で行うため、customerId がコンテナーの適切なパーティション キーになります。
customerId を選択すると、頻繁に実行される操作に対して 1 つのパーティション クエリが提供されます。
これで、この NoSQL データベースのすべてのリレーショナル エンティティがモデル化されました。 そこで、さらに最適化を行うことができる場所を調べましょう。
最適化の機会を特定する
salesOrder コンテナーを見ると、顧客コンテナーと同じパーティション キーを共有していることに気付くかもしれません。 顧客コンテナーのパーティション キーは ID で、salesOrder のパーティション キーは customerId です。 データがパーティション キーを共有し、似たアクセス パターンを持っている場合、それらを同じコンテナーに格納することができます。 NoSQL データベースである Azure Cosmos DB はスキーマに依存しないため、スキーマが異なるエンティティを混在させることは、可能なだけでなく、これらの条件下ではもう 1 つのベスト プラクティスでもあります。 ただし、これら 2 つのコンテナーのデータを結合するには、スキーマをさらに変更する必要があります。
最初に、customerId プロパティを各顧客ドキュメントに追加する必要があります。 これで、顧客の ID と customerId の値は同じになります。 次に、コンテナーで顧客と販売注文を区別する方法が必要です。 そこで、各エンティティに値が type と customer である salesOrder という識別子プロパティを追加します。
それらの変更により、顧客データと販売注文データの両方を新しい顧客コンテナーに格納できるようになります。 各顧客は独自の論理パーティションに格納され、1 つの顧客項目とすべての販売注文を持つようになります。 2 番目の操作については、顧客のすべての販売注文を一覧表示するために実行できるクエリがあります。