0

にはさまざまなタイプのアセットがあり、テクノロジーベースのアセットの一部には IP 列が必要であり、この IP は一意である必要があります。しかし、非技術資産には IP 列さえありません。現在、次のようにデータを保存しています:- ここに画像の説明を入力

しかし、IP アドレスを保存する場所がわかりません。次の方法があります。

  1. これを「Asset」親テーブルに保存して、一意のキーとして設定し、テクノロジーベースのアセットが同じ IP を持つことがないようにします。ただし、欠点は、すべての非技術資産の IP 列が常に null になることです。
  2. 2 番目のアプローチ。各テクノロジ ベースのテーブルに IP 列を追加することです。これにより null 値は回避されますが、一意であることを保証するにはカスタム作業が必要です。すべてのテクノロジーベースのアセットではなく、テーブルごとにのみ一意性を保証できるため..

それで、私が従うべきアプローチについて誰でもアドバイスできますか、または私が気付いていない別のアプローチがありますか?

ブラジル

:::編集:::

私は現在、次のデータベース構造を持っています:- ここに画像の説明を入力

現在、私はこれらの点を見ています:-

  1. ベース資産テーブルに冗長な AssetTypeID 列を導入したので、テーブルを結合しなくても資産タイプを知ることができます。これにより、正規化が壊れる可能性があります。

  2. 上記のアーキテクチャでは、IP を持つべきアセット、IP を持つべきでないアセット、および複数の IP を持つことができる/できないアセットを (データベース レベルで) 制御できません。これらの 2 つの点を処理するために私のアーキテクチャを改善する方法はありますか。

助けてくれてありがとう。

4

1 に答える 1

1

TechnologyAssetから継承 する別のテーブルを作成できますAsset。その後ServersRouterから継承できTechonlogyAssetます。

編集:

あなたの2番目のコメントは物事を完全に変えます。提示されたオプションのいずれも、単一の資産に複数の IP アドレスを許可しません。その場合IPAddresses、 への外部キーを持つテーブルを作成する必要がありますAsset。このようにして、特定のアセットに対してゼロ、1 つ、または複数の IPAddresses を持つことができます。

2番目の編集:

ポイント#1に関しては、はい、データが破損または無効になる可能性があります。パフォーマンスとエラー防止の間には固有のトレードオフがあります。インデックスを作成するとパフォーマンスが向上し、正規化も維持されますが、その TypeId を世界中のすべてのインデックスに追加するパフォーマンスに勝るものはありません。

ポイント 2 に関しては、IP の一意性を維持しながら、ある資産に 1 つの IP を持たせ、ある資産に 0 を持たせ、他の資産にアーキテクチャーの観点から複数の IP を持つ能力を強制することはかなり難しいと思います。私は何かを作成していましたが、クエリを実行して挿入するのは本当に面倒で、更新は気にしません。

アプリケーションのビジネス ルールやストアド プロシージャなどを通じて、そのようなルールを適用することをお勧めします。

于 2013-06-26T23:37:10.693 に答える