9

私はジレンマを抱えています。私は多くのレガシーコードを扱っていますが、テーブル構造に多くの冗長な情報があります。主に2つの形式で存在します。

A.「結合」を節約するための冗長な情報。例えば：

event_id, event_name, event_creator_id
       3       test1                43

subevent_id, event_id, event_creator_id 
         21         3               43

event_creator_idの重複に注意してください。かつての「シニア」開発者によって与えられた理論的根拠は、イベント作成者IDが必要な場合、値を取得するために「高価な」結合を行わずに、1つのテーブルをクエリするだけでよいということです。

B.計算を節約するための冗長な情報。例えば：

event_id, event_default_price
       3                  100

discount_id, discount_code, discount_percentage
          7,          ABCD,                  50

special_event_id, event_id, discount_id, discounted_price
              21         3            7,               50

この特別なイベントの最終的な「discounted_price」を計算する代わりに（discount_idへの参照がすでに存在するため）、コードはその「計算された」値をここにあるように保存していることに注意してください。繰り返しますが、正当化は「スピード」であり、通常は地獄に撃たれます。

2つの質問があります：

  1. これらの構造は正規化されていないことを新しい開発者に伝えることはできますが、彼らはより速く言うことができます。どうすればそれに対抗できますか？私はそれに対抗しますか？他の人はこのようにデータベースを構築していますか？！
  2. 経験則、または私が言うために使用できる一連の原則はありますか？
4

2 に答える 2

18

あなたの2つの質問について：

新しい開発者には、これらの構造は正規化されていないと言えますが、そのほうが速いと言えます。どうすればそれに対抗できますか？私はそれに反対しますか？他の人はデータベースをこのように構成していますか?!

それはより速いかもしれませんが、必ずしもそうではありません: テーブルに追加情報 (あなたの場合は追加フィールド) を追加することを決定するときはいつでも、テーブルが大きくなるため、パフォーマンスのペナルティも追加されます。サーバーからクライアントへ、またはメモリのページインまたはページアウト...また、クエリを高速化するためにフィールドがある場合、おそらくこれに1つ以上のインデックスがあり、更新および挿入中にパフォーマンスが低下します。ただし、重要な点は、私のコメントでほのめかしたことです。「キャッシュされた」値と「事前に計算された」値は、データの整合性に関してシステムをより脆弱にします。誰かが元の値を修正した場合でも、「event_creator_id」が常に実際の作成者を正しく指していると確信していますか? はいの場合、これにもコストがかかります。

「割引価格」や現在の合計などの集計値についても同じことが言えます...元のデータを変更することは、おそらく「イベント作成者」情報を変更するよりもはるかに頻繁です。繰り返しますが、誰かが販売を完了するたびに合計販売額が再計算されるようにする適切な「キャッシュ無効化」メカニズムはありますか? 返品された商品はどうなりますか？完全性を確保するためのコストを考慮した人はいますか?

実行中の合計やその他の派生値は、代わりにビューを使用して実装する必要があります。これにより、キャッシングがあれば、これを適切に処理する方法を知っている実際の DBMS エンジンによって実行されます。

「ああ、遅くなりますが、1％だけなので、このようにしても問題ありません」などと言うために使用できる経験則または一連の原則はありますか?

DB (またはほぼ間違いなくあらゆる種類のコンピューティング システム) は、「最初に正しい」必要があります。これにより、「十分に速く、2 番目に」それを実現する方法を見つけることができます。DB を設計するときは、正確性よりも正確性の方がはるかに重要であることがわかっている場合を除き、正確性を速度と引き換えにすることはすべきではありません。つまり、あなたの要件は、間違っている可能性のある情報や古い情報を持っていることは、応答時間よりも重要ではないことを明確に述べています.

言い換えれば、冗長なキャッシュ情報を持つテーブルを設計することは時期尚早な最適化のもう 1 つの例であり、絶対に避けるべきです。

これも参照してください-特に答え

于 2012-07-06T11:33:56.610 に答える
0

私がリレーショナル設計について読んだデータベースの本には、「計画された」冗長性または「制限された」非正規化に関するセクションが常に含まれていました。環境によって異なります。Wells Fargo は、銀行取引明細書の合計を事前に計算し、事前計算を保存します。

ステートメントを印刷するために各サイクルの終わりまで待っていた場合、これらの計算にかかる時間を想像してみてください。

計画的な冗長性は正常です!

于 2015-06-11T21:28:06.190 に答える