2

私は、生の「低レベル」テーブルに変更を加えて、理想的には、基になるデータに基づいてビューを格納するさまざまな異なるテーブルを自動的に伝播する必要があるシステムに最適なデータベース/データアーキテクチャアプローチを見つけようとしています。

簡単な例を挙げましょう。

次のテーブルがあると想像してください。

  1. さまざまなスーパーマーケットでの食材と価格のさまざまな表
    • 例えば。{ケチャップ：1.19、バター：0.99}のSafewayテーブルと、{卵：1.99、バター：0.79}のウォルマートテーブル
  2. 各材料の最も安い場所を格納するテーブル
    • 例えば。{バター=>ウォルマート：0.79}
  3. レシピの最も安い価格でレシピを格納するテーブル（表2の材料の最も安い価格から構成されます。
    • 例えば。{"ketchupy-egg-breakfast =>合計：3.97、材料=>バター：0.79、卵：1.99、ケチャップ：1.19
  4. いくつかの代替レシピの中で最も安い朝食レシピを格納するテーブル。

ここで、作業員が外出して、テーブル（1）の値を1時間ごとに更新していると想像してください。表1で変更されたものに依存し、同様に変更を表3と表4に伝播する、表2のエントリの更新を強制するデータベース設計またはアーキテクチャはありますか？一連のカスケードジョブですが、それを行うためのより複雑でよりエレガントな方法があるかどうか疑問に思いました。

ご協力いただきありがとうございます。

4

2 に答える 2

2

CQRSパターンによく合うように見えます。アイテムを保存するときは、データソースを1つだけ持つ必要があります。

リンクされた記事から：

CQRSは、Command QueryResponsibilitySegregationの略です。グレッグ・ヤングが最初に聞いたパターンです。その中心となるのは、情報の読み取りに使用するモデルとは異なるモデルを使用して情報を更新できるという単純な概念です。

CQRSは、ある種類の情報（モデルの更新）を取り込んで、それをクエリ可能なもの（読み取り/クエリモデル）に変換するのに役立ちます。

于 2012-04-19T12:25:38.137 に答える
2

「エレガントな方法」は、テーブルを適切に正規化することだと思います。

たとえば、Safeway用の1つのテーブルと、Walmartなど用の別のテーブルはありません。代わりに、SafewayとWalmartの両方を一覧表示する「Retailer」用の1つのテーブルと、卵、ケチャップなどを一覧表示する「Product」用の1つのテーブルがあります。次に、3番目に、retailer_id、product_id、priceなどをリストする「retail_item」と言います。

次に、あなたが提起したすべての質問を簡単に照会できます...

于 2012-04-19T12:29:45.420 に答える