SQL Server DBの設計時のシナリオがあります。データベースにさまざまな組織（つまり、顧客、ベンダー、ディストリビューターなど）に関するデータを保存する必要があります。すべてのdiff組織は、（ほぼ）同じタイプの情報を共有します..アドレスの詳細など...そしてそれらは他のテーブルで参照されます（つまり、OrgIdを介してリンクされ、多くのdiffの場所でOrgNameを検索する必要があります）
2つのオプションがあります。
OrgCustomer、OrgDistributor、OrgVendorなどの組織ごとにテーブルを作成します...すべてのテーブルは同様の構造になり、一部のテーブルには、顧客がフィールドHomeAddress（他のOrgテーブルにはない）を持つように特別なフィールドがあります。 ） .. およびその逆。
共通のOrgMasterテーブルを作成し、すべての差分組織を1か所に保存します。テーブルには、Orgのdiffタイプを区別するためのOrgTypeフィールドがあります。そして、特別なフィールドがOrgMasterテーブルに追加されます（関連するOrgレコードのみがそのようなフィールドに値を持ち、それ以外の場合はNULLになります）
＃1のいくつかの長所と短所
長所：
- 組織データのdiffタイプにアクセスする際に負荷を分散するのに役立つため、パフォーマンスが向上すると思います。
- 他の既存のOrgタイプに影響を与えることなく、特定のOrgテーブルをカスタマイズするための完全なスコープを提供します。
- 差分/分散テーブルの差分インデックスが単一の大きなテーブルよりもうまく機能するかどうかはわかりません。
短所：
- デザインの複製。ZipCodeフィールドのサイズを増やす必要がある場合は、すべてのテーブルで行う必要があります。
- 操作の実装におけるレプリケーション（つまり、CRUD操作にストアドプロシージャを使用したため、レプリケーションはn倍になります..3-4 Inert SP、2-3 SELECT SPなど...）
- DB制約\インデックス作成からSP、アプリケーションコード内のビジネスオブジェクトまで、すべてがn倍に拡大します。
- ある場所での変更（共通）は、他のすべての場所でも行う必要があります。
＃2のいくつかの長所と短所：
長所：
- N倍は1倍になります:-)
- すべての操作に対して単一のエントリポイントを実装できるため、メンテナンスが容易になります（つまり、CRUD操作を処理する単一のSPなど）。
- 単一のテーブルを維持することを心配する必要があります。インデックス作成およびその他の最適化は、単一のテーブルに制限されています。
短所：
- ボトルネックが発生しますか？ビューやその他の最適化されたデータアクセス戦略を実装することで管理できますか？
- 一元化された実装のもう1つの側面は、すべての場所で1つの変更をテストおよび検証する必要があることです。抽象的ではありません。
- デザインは、特に「組織化/構造化」されていないように見えるかもしれません。'特別な'フィールド（他のテーブルとは無関係）を追加する必要があるいくつかの組織のため
また、オプション＃3-Orgテーブルを分離したまま、共通のフィールドを格納するための共通のOrgAddressテーブルを作成することも念頭に置いています。しかし、これは私を＃1と＃2の真ん中に連れて行き、さらに混乱を引き起こしています！
正直なところ、私は経験豊富なプログラマーですが、同じように経験豊富なDBAではありません。これは私の主流の仕事ではないため、設計の複雑さやパフォーマンスなどのパラメーター間の正しいトレードオフを導き出すのを手伝ってください。
前もって感謝します。技術的な質問や提案は大歓迎です。
ヘマント
