4

アプリケーションの機能の状態を監視するためのデータベースを作成しています。ロジックは次のとおりです。

各アプリケーションには、私が監視している独自の特定の機能リストがあります。各機能は、1 つのアプリケーションのみに属します。アプリケーションへの外部キーを持つ機能テーブルがあります

各アプリケーションは、1 つ以上のマシンで実行されます。各マシンは、1 つ以上のアプリケーションを実行できます。これは MTM 接続なので、ApplicationInstance テーブル接続アプリケーションとマシンがあります。

実際の監視は、ApplicationInstance のクエリに関するものです。問題がある場合、それに関する情報は、ApplicationInstance への外部キーを保持する AppInstanceError テーブルに送られます。クエリが成功すると、各機能のステータスのリストが取得されます。したがって、ApplicationInstance と Functionality への外部キーを持つ FunctionalityStatus テーブルがあります。

これは一種の悪い設計だと思います。なぜアプリケーションへの複数の参照があるのでしょうか? 両方が同じアプリケーションを指すことを保証するものは何ですか? または、これを確実にする方法はありますか？

したがって、私の修正案は、FunctionalityStatus を外部キーで Machines & Functionality に接続することです。しかし、この場合、彼らは ApplicationInstance を定義しているので、各ペアに ApplicationInstance があるという保証は何ですか? 何らかの形で接続すべきではないでしょうか。現実の世界では接続が存在し、それは明白なので、データベースに存在しなくても問題ないでしょうか?

この問題を解決する、またはデータ設計から見えない接続を確保する「適切な方法」はありますか?

より明確にするために、現在持っている DB の設計を準備しました。 DB設計

欠けているのは、FunctionalityStatus から Machine への接続だけです。このような接続を行うには、次の 2 つの方法があります。

  1. 外部キーを ApplicationInstance に追加します - 次に、私の疑問は次のとおりです。
    • Functionality の ApplicationId が ApplicationInstance の ApplicationId と同じであることを確認するにはどうすればよいですか?
    • このデータの複製は本当に必要ですか?
  2. マシンに外部キーを追加 - そして疑問:
    • すべての FunctionalityStatus レコードに適切な ApplicationInstance レコードがありますか?
    • ApplicationInstance と FunctionalityStatus の間に明らかな関連がある場合 (最初の疑問で言及)、データベースでそれを確認できないのはなぜですか?
    • ここでも、すべての ApplicationInstance レコードが FunctionalityStatus テーブルに表示される (または表示されるはず) ため、データの冗長性が確保されます。

それとも、デザイン全体が台無しになっていて、まったく別のことを考え出す必要があるのでしょうか?

4

3 に答える 3

1

あなたのデザインは私にはうまく見えます。オプション 1 を選択し、外部キーを からFunctionalStatusに追加しApplicationInstanceます。

FunctionalStatusそれを確認して同じアプリケーションを参照したい場合はApplicationStatus、新しい column を追加しFunctionalStatus.ApplicationId、外部キーをFunctionalStatusからApplicationStatusinclude にすることができますApplicationId。FunctionalStatusからへの外部キーについても同様ですFunctionality。

言い換えれば、次のようなもの

CREATE TABLE application
    ( application_id          INT PRIMARY KEY
    /* Other columns omitted */
    );
CREATE TABLE application_instance
    ( application_instance_id INT PRIMARY KEY
    , application_id          INT REFERENCES application(application_id)
    , machine_id              INT REFERENCES machine(machine_id)
    /* Other columns omitted */
    );
CREATE TABLE functionality
    ( functionality_id        INT PRIMARY KEY
    , application_id          INT REFERENCES application(application_id)
    /* Other columns omitted */
    );
CREATE TABLE functionality_status
    ( functionality_status_id INT PRIMARY KEY
    , application_id          INT REFERENCES application(application_id)
    , functionality_id        INT /* Part of composite foreign key, see below */
    , application_instance_id INT /* Part of composite foreign key, see below */
    /* Other columns omitted */
    FOREIGN KEY (functionality_id, application_id) 
      REFERENCES functionality(functionality_id, application_id)
    FOREIGN KEY (application_instance_id, application_id) 
      REFERENCES application_instance(application_instance_id, application_id)
    );
于 2010-02-23T05:25:34.187 に答える
0

それが私だったら、これは私がそれを行う方法です：

  1. Machine、Application、Functionality、ApplicationPool、および Log の 5 つのテーブルを作成します。
  2. Functionality に FK 列を配置します。これは、Functionality が存在するアプリケーションの ID です。
  3. ApplicationPool には、マシン ID 列、アプリケーション ID 列、GUID またはシード ID のいずれかである主キー、ApplicationName + PK である ApplicationInstance ID があります。可能であれば、これを使用してアプリケーションにマシンの名前を付けます。
  4. 最後に、ログ テーブルを作成し、ApplicationPool の PK を参照する FK 列を指定します。次に、何かを記録するたびに、それを Log テーブルに追加すると、アプリケーションに関するすべての情報が個別に保存されます。

これが近くない場合は、あなたが探しているものを誤解している可能性があるため、お知らせください。

于 2010-02-22T19:33:47.213 に答える
0

発生する可能性のある最大の問題は、同じマシン上の同じアプリケーションの 2 つの異なるインスタンスに対して同じインスタンス ID を持つことが常に可能であるということです。同時にはできません。インスタンス ID は時間の経過とともに再利用され、アプリが同じ ID を再び取得する可能性がわずかにあります。

この種のことを行う場合、起動時に各アプリケーションに GUID を割り当てます。これにより、同じ GUID を持つ 2 つのアプリケーションを持つことができなくなり、その GUID を関係に使用できます。各マシンが他のマシンと同じ GUID を作成することはないため、リレーションシップにマシン情報を含める必要さえありません。

これに答えた後、私は本当にあなたの本当の質問に答えていないことに気付きました. 特定の機能が特定の方法で機能しているかどうかを確認する場合は、その機能が意図したとおりに機能していないマシンとアプリケーションに関連づけることをお勧めします。 1つ間違っています。

マシン用、アプリケーション用、機能用の 3 つのテーブルを持つことが、最適なデータベース設計です。何をしているかにもよりますが、特にマシンとアプリケーションに関する情報がとにかく 1 つのフィールドにすぎない場合は、ソフトウェアが、使用している機能のセットごとにすべてのアプリケーションとマシンの情報を複製する方が簡単で高速な場合があります。できれば、この情報のログ記録の機能を遅くしたくないので、迅速に実行したいと考えています。

于 2010-02-22T17:22:57.030 に答える