私の質問は、同様に関連するテーブルのために、2 つのジャンクション テーブルを 1 つに結合するという考えについてです。私が何を意味するかを理解するために読んでください。また、これは実際に私が直面している問題であり、したがってこのフォーラムに関連していることにも注意してください。これは幅広い結果をもたらすトピックに過ぎず、さまざまな専門家からもう少し多くの参加を得て、「ベスト プラクティス」のより良い調査を行うことを望んでいます。
このかなり難しいデータベース設計の問題があります。これが、多くの人が貢献し、学ぶことができる wiki のようなものになることを願っています。これを簡単にするために、一連の図を作成し、問題を 1) プロセスと 2) 構造に分解します。
プロセスステップ
- ドキュメント (Publication) の要求 (DocRequest) が行われます。
- パブリケーションがまだ存在しない場合は、新しいパブリケーションが作成されます。
- 実行中のログ (StatusReport) は、要求を満たす進行状況のために保持されます。
注: 特定の発行物に対して、多数の DocRequest および StatusReport (更新を含む) が存在する場合があります。
データベース構造
注: DocRequest テーブルと StatusReport テーブルの両方に、添付の図には示されていない多数のフィールドとサポート テーブルがあります。さらに、特定の発行物は、それらのテーブル内のすべてのレコードが属するマスター レコードです。
-- 現在の実装 --
注: この設計の主な欠点は、新しい DocRequest レコードと StatusReport レコードのいずれかを作成するたびに、Publications テーブル (接合テーブルのように機能する) にも新しいレコードを作成する必要があることですが、これにより新しい Publication も作成されます。結果。これは望ましい動作ではありません。
-- 典型的な実装-- (このタイプの関係の場合)
注: これは問題なく、おそらく理想的ですが、DocRequest テーブルと StatusReport テーブルのいずれかに対する更新を処理し、それらが属するパブリケーションに個別にリンクします。
--私の推奨する実装-- (この特殊なケースの場合)
注: ここで私が思いついたのは、単純にデュアル ジャンクション テーブルを 1 つに結合することでした。この場合、ジャンクション テーブルは、DocRequest または StatusReport で挿入が発生するたびに新しいレコードを取得します。私はおそらくこれをトリガーで処理します。
討論
では、議論を始めましょう。これが悪い考えであると思われる場合は、仲間のデータベース開発者に知らせてください。また、これによりどのような問題が発生する可能性があるかを知りたいです。レコードの正味数は、2 つの別個のジャンクション テーブルの場合と同じである必要があり、実際には、追加の ID 列を節約することで使用するスペースがわずかに少なくなると思います。:)
皆さんの考えを教えてください。多くの方にこの議論に参加していただきたいと思います。乾杯!:)