あなたのデザインは私にはよく見えます。私は常に、システムが本番環境に入った後にデータを再編成するのに時間を費やすよりも、設計段階でいくつかの結合を追加することを好みます。経営陣、営業担当者、財務担当者からどのようなレポートが要求されるかを事前に知ることはできません。適切な関係設計により、自由度が高まります。
JOINまた、パフォーマンスの問題について、いくつかの余分な s だけを責めることはできません。常に以下を確認する必要があります。
- データ ボリューム (および物理データ レイアウト)、
- 取引量と密度、
- I/O、CPU、メモリ使用量、
- RDBMS 構成、
- SQL クエリの品質。
私の見解では、JOINs はこのリストの一番下にあります。
RI 制約(参照整合性) に関しては、パフォーマンスを向上させるために主キー/外部キーなしで実行されていたプロジェクトをいくつか見てきました。主な言い訳は、アプリケーションにすべてのチェックが組み込まれており、アプリケーションがシステム内の変更の唯一のソースであるということでした。一方で、システムが一貫した状態にあったかどうかは不明であることに同意しました (実際、分析では一貫していないことが示されました)。
私は常に、設計状態に関するすべての可能なキー/制約を作成することに固執します。なぜなら、あなたのデータベースを掘り下げて、より適していると思われるデータを「調整」する「カウボーイ」が常に周りにいるからです。それでも、公式の推奨事項でもある、一括データ操作のためにいくつかの制約/インデックスを一時的に無効にするか、削除することもできます。
不明な場合は、2 つのテスト データベースを作成します。1 つは制約あり、もう 1 つは制約なしです。データを読み込んで、クエリのパフォーマンスを比較します。似たようなものになると思います。
ここにあなたのスケッチに対する私のコメントがあります。決定はすべてあなた次第です。
テーブルに単数形の名前を付けることを好むのはなぜですか? table私は常に_idパターンを使用してPKに名前を付けているため、IMHOpharmacy_idの方が見栄えがよくなりpharmacies_idます。メインテーブルにロードする前にデータの一貫性チェックを実行するときに、このパターンに依存する汎用スクリプトがたくさんあるため、このアプローチを使用します。
編集：
連絡先の詳細。アプリケーションでこれが何を意味するとしてもcontact_id、すべてのテーブルで使用して、それを主要な連絡先にすることができます。いくつかの関係のためにさらに多くの連絡先が必要な場合はowner_contact_id、sales_contact_id、 などの別の接頭辞を使用できます。
のようないくつかのリレーションに膨大な数の連絡先が存在すると予想される場合は、次のようpharmacygroupに追加のテーブルを追加できます。
CREATE TABLE pharmacygroupcontact (
contactid int4,
groupid int4,
contact_desc text
);
あなたのイニシャルgroupcontactsを部分的にコピーしますが、2 つの FK と説明で構成されています。アプリケーションがどのように設計されているかを知らないため、どちらのアプローチが優れているかはわかりません。
