1

すでにこの状況に対処している方に、経験を共有していただくようお願いしています。

使用事例 ：

ビジネス注文がシステムに届く > アクティブになる > 注文が受理されるか期限切れになる > 処理待ち > 正常に処理されるか失敗する。

分かりますか ？エンティティには少なくとも 4 つの状態があります。私がやっていることは、メインのテーブル「注文」と、orderIds (アクティブ、期限切れ、保留中、履行済み) のみを含む他の 4 つのテーブルがあり、さまざまな状態の注文を照会するときに JOINS を実行していることです。

このようにして、巨大なテーブル Order は読み取りのみで書き込みは行われないため、パフォーマンスの観点から非常に効果的です...

このユースケースのテクニックは何ですか?

4

1 に答える 1

0

このユースケースでは、パフォーマンス（書き込みの除去）のために追加のテーブルが必要であることは間違いありません。ただし、テーブルが4つあると、次の反復で多くのメンテナンスの問題が発生する可能性があります。

私はおそらくOrderStatusCodeテーブル（orderId、statusId）のみを作成し、次のようにJOINSを実行できます。

select * from order 
   inner join activeorder 
      on 
   order.orderID = activeorder.ActiveOrderID 
      WHERE activeorder.status = 'l'

しかし、ビジネスサイクル全体に関しては、エンティティの状態が6〜10回以上変化することはないと思います。すべてを1つのテーブルにまとめるのに問題はありません。「wherestatus_id=x」を選択するために、status_idに適切なインデックスがある場合。ただし、一方で、テーブルを追加すると、ステータスコードに関するいくつかのプロパティを簡単に追加できます。

于 2011-03-04T14:48:03.217 に答える