0

生産追跡に関連するデータを格納するためのデータ モデルの作成に取り組んでいます。私は、クライアントのデータをモデル化および分析するエンジニアリング会社で働いています。プロセスにはいくつかのステップがあり、プロセスは常に更新されています。

プロセスをモデル化し、親プロセスとプロセスの順序を含めようとしています。

例えば：

Process Table
---------------------
ProcessID - uniqueidentifier
ProcessName - varchar
ProcessDescription - varchar
...

ProcessOrder Table
---------------------
ProcessID - uniqueidentifier FK - Process
ParentProcessID - uniqueidentifier FK - Process
ProcessOrder - int
...

テーブルのProcessOrder列はProcessOrder、親プロセスのどの連続ステップを表すかを表す番号を格納するだけです。

たとえば、モデリング手順には次のステップがあります。新しい空のモデルを作成し、モデルに名前を付け、モデル パラメータを入力します。テーブルは次のProcessようになります。

ProcessID | ProcessName | ProcessDescription
-------------------------------------------------
UUID1     | Modeling    | Create Model of Data
UUID2     | New Model   | create new empty model
UUID3     | Name Model  | name model
UUID4     | Parameters  | enter model parameters

テーブルは次のProcessOrderようになります。

ProcessID | ParentProcessID | ProcessOrder
--------------------------------------------------
UUID2     | UUID1           | 1
UUID3     | UUID1           | 2
UUID4     | UUID1           | 3

この設計の問題点は、ワークフローが更新されると、プロセスの順序が変更され、ProcessOrder変更されたプロセスのレコードと、同じ を持つ後続のすべてのレコードのレコードを更新する必要があることParentProcessIDです。

この種のデータを保存し、正規化を維持するためのより良い方法はありますか?

4

2 に答える 2

0

このソリューションは、プロジェクト ライフサイクルのデータベース設計に関するアドバイスで提案したものと似ていると思います

上記のデータは、前の例で説明したさまざまなステータス値のデータです。したがって、クライアント プロジェクトごとに次のテーブルがあります。

a) クライアント プロジェクト - Clientid - クライアントへの参照 - ステータス (ProcessID への外部キー) - プロジェクト名、説明、開始日

b) ステータスの変更 - あるステータスから別のステータスへの変更を追跡します - projectid - 古いステータス (FK から ProcessID へ) - 新しいステータス (FK から ProcessID へ) - 変更日 - メモ (および承認などの他の列)

于 2012-07-07T10:35:28.360 に答える
0

この問題は、LinkedList の挿入パフォーマンスが向上する理由 (挿入するノードへの参照が既にある場合) と ArrayList への挿入に似ています。

ArrayList で挿入を行う場合、すべてのレコードを移動して、新しい挿入用のスペースを確保する必要があります。これには、N レコードを想定すると O(N) 時間がかかる場合があります (リストの先頭に挿入することを想像してください)。

LinkedList では、挿入したいポイントでノードを更新するだけで済みます。上記の仮定では、前のノードと次のノードのみを更新する必要があるため、これには O(1) 時間がかかります。

ProcessOrder 列の代わりにデータベースに LinkedList 構造をセットアップするには、PrevProcessID と NextProcessID の 2 つの列を用意します。

これを選択するときに問題が発生します。単純なアプローチは、テーブルで再帰的に自己結合することです。これにより、N 個の結合が発生します。

N 結合を使用する代わりに、結合を使用せずに、親 ID を持つすべてのプロセスを選択します。

コードでは、次のフィールドを持つ Process オブジェクトを用意します。 ParentProcessID ProcessID PrevProcessID NextProcessID

選択からレコードを読み取りながら、これらのオブジェクトを作成し、ProcessID をキーとして HashTable に格納します。これは、select ステートメントをループするのに O(N) 時間かかります。

レコードが HashTable に格納されたので、テーブル内の NextProcessID (または PrevProcessID) を検索することで、1 つのノードから次のノードに簡単に移動できます。HashTable を使用すると、N 個の結合を行う必要がなくなり、セットアップに O(N) 時間かかります。

2 つのアプローチの比較

1) 現在持っている現在のソリューション。これは ArrayList タイプのソリューションです (ProcessOrder をインデックスと考えてください)。挿入には O(N) 時間かかりますが、HashTable をセットアップする必要がないため、読み取りの時間を節約できます。ただし、エンティティ オブジェクトをセットアップするために返されたレコードを既にループしている場合、これは LinkedList ソリューションでのセットアップ時間と同じ量になります。

2）私が提案した解決策。これは LinkedList タイプのソリューションです。挿入する場所がわかっていると仮定すると、挿入には O(1) 時間がかかります。セットアップ時間は O(N) 時間かかります。

于 2012-11-15T15:35:56.003 に答える