2

この表から始めましょう：

CREATE  TABLE IF NOT EXISTS `resourceMovement` (
  `resourceID` INT(4) UNSIGNED NOT NULL ,
  `movementDateTime` DATETIME NOT NULL ,
  `movementQuantity` INT(11) UNSIGNED NOT NULL ,
  `fromLocationID` INT(4) UNSIGNED NULL ,
  `fromIndividualID` INT(11) UNSIGNED NULL ,
  `fromDeptID` INT(4) UNSIGNED NULL ,
  `toLocationID` INT(4) UNSIGNED NULL ,
  `toIndividualID` INT(11) UNSIGNED NULL ,
  `toDeptID` INT(4) UNSIGNED NULL ,
  `lastUpdated` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ,
  PRIMARY KEY (`resourceID`, `movementDateTime`, `movementQuantity`) ,
  [ List of foreign key constraints. ]

これは、特定のリソースIDの特定の量が1つの部門/場所/人から別の部門/場所/人にどのように移動するかを時間の経過とともに追跡します。

私がやりたいのは...何かを作成することです。toLocationID / toIndividualID / toDeptID値をループし、それらの宛先に関連付けられた各resourceIDの実行中のインベントリーを生成するプロシージャーまたはトリガーまたはビュー。

これを効率的に行うには、MySQLストアドプロシージャがリモートで十分ではありません。

部門、場所、および個人用にそれぞれ1つずつ、合計3つの実行中の在庫テーブルを作成し、移動テーブルが更新されたときにそれらのテーブルを更新するトリガーを作成できると思います。そのためには、通常のテーブルと一時的なテーブルのどちらが適していますか？

そして、詳細な質問はちょうど来続けます。それで、私は一般的な質問を残します：実際の実行中の在庫を決定するために在庫の動きを監査するテーブルをスキャンするための最良の方法は何ですか？

ありがとう！

4

1 に答える 1

1

私は過去にこれに似たシステムを実装しました。これをいくつかのテーブルに分割するのが（私にとって）最もうまくいくようです。

リソース
-リソースID-
リソースの説明
-数量

変更
-IDの変更-
日付/タイムスタンプ
の変更-タイプの変更
-リソースID-
宛先ID-
数量

宛先
-宛先ID-
宛先タイプ

変更の種類は次のとおりです。-
ディストリビューターからの新しい在庫
-人/場所/イベントに一部を割り当てます
-在庫を破棄します
-保証交換
-販売

目的地は次のとおりです。-
人/場所/イベント-（あなたの場合は、部門、人、場所になります）

在庫がある量（合計）を確認するには：

リソースから選択

特定の目的地がどれだけあるかを知るには：

リソースから選択参加変更参加先スタンプ<=興味深いイベント

特定のアイテムの履歴を検索するには：

リソース=の変更から選択

したがって、継続的な更新を実行する必要はありません。変更を追跡するだけで済みます。これは、（合理的に）正規化された方法で行われます。

于 2013-03-13T17:47:02.250 に答える