0

多くの場合、構成要素または子メンバーから派生した属性を持つ集約エンティティまたは親エンティティを扱います。例えば：

  • オブジェクトのbyte_countandpacket_countは、TcpConnectionその2つの構成オブジェクトの同じ属性から計算され、2つの構成TcpStreamオブジェクトはそれらの構成TcpPacketオブジェクトから計算されます。

  • Invoicesオブジェクトtotalには、基本的にその構成要素InvoiceLineItemsの価格のSUM（）であり、わずかな運賃、割引、および税金のロジックがスローされている場合があります。

数百万のパケットまたは数百万の請求済み広告申込情報を処理する場合（私が望む！）、これらの派生属性のオンデマンド計算は、VIEWで、またはより一般的にはレポートやWebインターフェイスなどのプレゼンテーションロジックで、許容できないほど遅いことがよくあります。

パフォーマンスの懸念があなたの手を強制する前に、事前に計算されたフィールドに派生属性を「プロモート」するかどうかをどのように決定しますか？

4

3 に答える 3

3

パフォーマンスのトレードオフが私の手を強制するまで、私は個人的に非正規化することはありません（非正規化の欠点は、私見ではあまりにも劇的であるため）が、次のことも考慮する必要があります。

  1. 利便性：たとえば、2つの異なるクライアントアプリが同じ派生属性を計算する場合、両方がクエリをコード化して計算する必要があります。非正規化は、両方のクライアントアプリに派生属性をより簡単な方法で提供します。
  2. 時間の経過に伴う安定性：たとえば、派生属性を計算するための式が変更可能な場合、非正規化により、ある時点で派生値をキャプチャして保存できるため、将来の計算で間違いが発生することはありません。
  3. より単純なクエリ：DB構造に複雑さを加えることは、クライアント側でのSelectクエリがより単純になることを意味します。
  4. パフォーマンス：非正規化されたデータに対する選択クエリを高速化できます。

参照：データベースプログラマー：非正規化の引数。非正規化された値を正しく保つことに関する彼の記事も必ず読んでください-彼の推奨はトリガーを使用することです。これにより、非正規化に必要な種類のトレードオフが発生します。

于 2010-02-07T15:34:30.723 に答える
1

基本的に、あなたはしません。あなたはパフォーマンスの懸念を残しました。

これが最良の答えです。99％の場合、このように事前に最適化するべきではなく、その場で計算する方がよいからです。

ただし、クライアントアプリケーション開発者が「 ...派生属性のオンデマンド計算...は許容できないほど遅い」などの誤った先入観を持ってサーバー側に来ることは非常に一般的であり、これは真実ではありません。 。ここでの正しい言い回しは、「許容できないほど遅いことはめったにありません」です。

そのため、この専門家（DB開発アーキテクトなど）でない限り、時期尚早の最適化に従事するべきではありません。修正する必要があることが明らかになるまで待ってから、事前集計を確認してください。

于 2010-02-05T21:51:11.190 に答える
0

データがどれだけ最新である必要があるかによって、実際にデータを実装する方法が決まります。

現在または非現在の2つの単純な状態を想定します。

  • 現在：インデックス付きビュー、トリガー、集計テーブルを維持するためのストアドプロシージャなど
  • 最新ではない：Reporting Serviceスナップショット、ログ配布/レプリケーション、データウェアハウスなど

とは言うものの、私は本番環境と同じ量のデータに対して開発するので、応答時間にある程度の自信があります。コードのパフォーマンスに驚くことはめったにありません...

于 2010-02-05T21:51:53.097 に答える