0

stokとstok_detailの2つのテーブルがあります。Tablestockはテーブルstock_detailの要約です。

stokは、item_id、qty、costの3つの列で構成されます

在庫の詳細は、transaction_id、posting_date、item_id、qty、およびcostの5つの列で構成されます。

誰かが特定のトランザクションを編集すると、コストが再計算される可能性があります。

例:日付10の編集トランザクションの購入。日付10以降の後続のトランザクションのすべてのコストが再計算されます。

すべての計算をストアドプロシージャに入れました。

問題は、再計算するトランザクションが多数ある場合、このトランザクションに数時間かかる可能性があることです。また、トランザクションの実行中に電源がダウンし、stock_detailテーブルが破損する場合があります。

私の質問は:

計算を最初に一時テーブルに置く方が良いですか。例:stock_calc。すべての計算が完了すると、stock_calcから値を取得して、テーブルstock_detailが更新されます。したがって、テーブルstock_detailは、すべての計算が完了した後で後で更新されます。

したがって、問題が発生した場合は、テーブルstock_calcを空にします。トランザクションがstock_detailを更新しているときに、電源がダウンする可能性があることを私は知っています。ただし、確率は最小限に抑えられます。もちろん、計算に時間がかかります。しかし、それがより安全であれば、私はこのアプローチを検討するかもしれません。

皆さんはどう思いますか?コメントやアイデアは大歓迎です。

そしてもう1つ。電源が落ちた場合、データベースに再接続したときに、コミットされていないすべてのトランザクションを確認し、コミット/ロールバックすることはできますか?

4

1 に答える 1

1

Firebirdは、ACIDコンプライアンスを念頭に置いて構築されています。つまり、「理論的に」ネットワークまたは電源(ハードウェアを除く)に障害が発生した場合でも、データベースはその整合性を維持する必要があります。

ただし、特にハードウェア障害やFirebirdエンジンプログラミングのバグで、データが破損する場合があります。FBバージョンをメジャーバージョンの最新の安定版にアップグレードする必要があります。

また、大量のデータを変更するトランザクションを長時間アクティブにしておくことは、優れたアーキテクチャ設計ではありません。これは避けてください。

于 2012-12-17T19:40:22.700 に答える