2

私はいくつかの意見を探しているデータベース構造の問題を抱えています。

ユーザーがアプリケーションを使用して資料を要求するシナリオがあるとします。

リクエスタが誰であるかを追跡する必要があります。

リクエスタには 3 つの「タイプ」があります。個人 (Person)、部門、および材料自体を提供するサプライヤ。

さらに、仕入先オブジェクトも仕入先として関連付ける必要があります。

そのため、RequestedByID FK が存在する Request テーブルにアイデアがあります。しかし、関連するリクエスターは、それぞれのデータに対して非常に異なる構造を持っているため、単一のテーブルだけを作成した場合、関連付けるには完全に非正規化されたテーブルが必要になります (人は部門やサプライヤーとは異なるプロパティを持っています)。

これをどのように処理するかについていくつかのアイデアがありますが、SO コミュニティには大きな洞察があると思いました。

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

編集：

疑似構造:

リクエスト

RequestID リクエスタID

デパートメント

DepartmentID DepField1 DepField2

人

PersonID PersonField1 PersonField2

サプライヤー

サプライヤーID SuppFiel1 SuppField2

Department、Person、および Supplier はすべて、プロパティがかなり異なるため、個別のテーブルを持ちます。ただし、それぞれがリクエストのリクエスタ (RequesterID) として機能できます。さまざまな可能なリクエスタでいっぱいの 1 つ (非正規化されたテーブル) なしでこれを達成するための最良の方法は何ですか?

お役に立てれば。. .

4

4 に答える 4

2

次のような継承 (別名、カテゴリ、サブタイプ、一般化階層など) として知られている ER モデリングにあるものが必要です。

ここに画像の説明を入力

このように、リクエスタの種類ごとに異なるフィールドと FK を簡単に設定できますが、REQUEST テーブルは 1 つしかありません。基本的に、要求を変更することを余儀なくされることなく、要求者を変更できます。

通常、物理データベースで継承を表す方法は 3 つあります。あなたが試したのは基本的に戦略＃1（すべてのクラスを単一のテーブルにマージする）ですが、戦略＃3（すべてのクラスを別々のテーブルにマージする）をお勧めします。

于 2012-07-19T08:22:39.037 に答える
0

RequesterID と RequesterTypeID の 2 つの異なる ID を持つことができます。RequesterTypeID は、Person、Department、Supplier に対してそれぞれ 1、2、または 3 になり、RequesterTypeID と RequesterID を組み合わせると、複数属性の主キーが作成されます。

于 2012-07-19T01:51:14.717 に答える
0

Jack Radcliffe の考えで私が気に入っているのは、それらを別のテーブルに格納するか、SQL ステートメントを汎用にして、アプリケーションから渡された任意の数値を処理すると、製造、エンティティ、子会社などに拡張できることです。

ただし、拡張を選択するとオーバーヘッドが発生します。

于 2012-07-19T02:14:28.603 に答える
0

ジャック・ラドクリフが提案したことは、おそらく最良の選択肢です。したがって、代替オプションを追加するだけです：

また、3 つの要求テーブルを持つことを検討することもできます... 1 つは ppl 要求用、1 つはサプライヤー要求用、もう 1 つは部門要求用です... したがって、RequesterTypeID を明示的に保存する必要はありません。テーブル...その後、3 つの個別のテーブルすべてを「結合」することにより、Jack Radcliffe テーブルをビューとして作成できます...

また、Jack Radcliffe アプローチを実装する場合は、3 つのビューを作成して、私が言及した 3 つのテーブルをシミュレートできます...したがって、状況ごとに最適なテーブル/ビューを使用でき、アプローチ A から変更する場合Bも本当に簡単です...

于 2012-07-19T01:56:05.903 に答える