クエリ ストアで複数のテーブルを使用することをいつ検討すべきかを知りたいです。
たとえば、製品の説明が変更された問題を考えてみましょう。この変更は、製品の説明を含む多数の集計がある場合、読み取り専用クエリ ストアの同期に大きな影響を与える可能性があります。
時間のかかる同期の問題を回避するために、どの時点でデータのわずかな正規化を検討する必要がありますか? これはノーノーまたは容認できる妥協ですか?
ありがとう、
1 に答える
8
CQRS は table-per-view を使用することではなく、table-per-view は CQRS がより簡単にするシステムの側面です。
それはあなた次第であり、特定のコンテキストとニーズに依存します。私はこのように考えます。そのクエリの最終的な一貫性のコストと、高いクエリ パフォーマンスの必要性との対比です。システムの次の 2 つの特性を考慮する必要がある場合があります。
1) 平均 そのコマンドの一貫性、つまり、コマンドの影響を受けるすべての読み取りモデルを更新するのにかかる時間 (また、変更用に最適化されたストアド プロシージャが、ORM やその他の抽象化を使用してこの方法でデータベースを更新するよりも優れているかどうかも検討してください) ）。
私の推測では、何百万ものレコードについて話しているのでない限り、ここでの一貫性は、要件と一貫性に対するユーザーの期待を満たすのに十分であり、おそらく数秒です。
2) クエリ パフォーマンスの重要性。毎秒何件のクエリを取得していますか? 毎回 SQL 結合を処理できますか?
ほとんどの実際的なシナリオでは、これらのいずれかの最適化は意味がありません。UI を更新するのに十分な一貫性がある優れた SP を使用して、レコードに関係なく、おそらく更新を行うことができます (コマンドを発行した UI は、コマンドが成功したことを知るとすぐに一貫性を保つことができることに注意してください)。
また、通常、単一の結合で問題が発生するほどシステム内でクエリをスケーリングする必要はありません。コードやストアド プロシージャでこれらの結合を実行することで、内部の複雑さが増すことは望ましくないかもしれません。
CQRS のすべてのものと同様に、最初からすべての側面を使用して最適化する必要はありません。これらを段階的に最適化できます。今日は結合を使用し、明日は完全に非正規化するか、その逆を行います。
于 2011-02-27T19:09:08.653 に答える