0

私は自分のデータベースを設計しており、将来的に条件付き結合を回避するための最良の方法を見つけようとしています. 条件付き結合を示す記事を読みましたが、可能であれば絶対に避けたいものです。

CHECKテーブルがあり、いくつCHECKかのデータ (金額、日付など) を保存します。また、3 つの「その他の」テーブル 、VENDORがありVENDOR_DEPT、VENDOR_ACCOUNTそのうちVENDOR_ACCOUNTの fk toVENDOR_DEPTとVENDOR_DEPTfk to がありVENDORます。

私の問題は次のとおりです: CHECK を に割り当てるか、テーブルに,を持たずにVENDOR、VENDOR_DEPTまたは列, , ...を持つ VENDOR_CHECK テーブルを持つようにモデルを設計するにはどうすればよいですか?VENDOR_ACCOUNTvend_idvendacct_idvenddept_idCHECKcheck_idvendor_leveljoin_id

よりクリーンな方法はありますか？ところで、私は MYSQL を使用していますが、このソリューションを他のプラットフォームでも動作させたいと考えています。

私はモデルの設計段階にいるので、もちろんこれらのテーブルの再設計を含むすべての提案を受け入れます :)

4

1 に答える 1

1

SQL で「one-of」関係を実装しようとしています。このタイプの関係は、少し難しい場合があります。それを解決する「リレーショナル」な方法は、実際に CHECK_ENTITY があり、このエンティティが 3 つのタイプのいずれかであるということだと思います。しかし、それは不必要に面倒に思えます。

1 つの提案は、テーブルに 3 つの異なる列を含めることです。私の推測では、レポート目的で vend_id を使用したいと思うことがよくあります。特定の CHECK に適切なものを入力するだけです。

はい、vend_id は CHECK テーブルと VEND_ACCT テーブルの両方にあるため、データは非正規化されます。アカウントと部門が変更された場合、これは CHECK 時の関係をキャプチャします。これは、必要な場合があります。

別のオプションは、「ベンダー全体」を意味するダミー アカウントを持つことです。次に、この値を使用して、ベンダー全体を意味します。同様に、部門ごとにアカウントが必要になります。

このアプローチには、ある程度の規律が必要です。親に戻るリンクを使用して、可能な限りの深さでベンダー階層を設定するのは魅力的です (アカウント --> 部門 --> ベンダー、それを一般化してみませんか?)。SQL は、one-of リレーションシップよりも階層クエリでさらに悪化します。「さらに悪い」とは、そのようなクエリを処理する方法がデータベースに大きく依存していることを意味します。

于 2012-11-30T15:01:51.993 に答える