パーティー プランナーが使用するソフトウェアを作成しているとします。これは、現在のデータベース スキーマがどのように見えるかです。
Parties ( PartyId, ClientId, DateTime )
Tents ( PartyId, TentDetails... )
Clowns ( PartyId, ClownDetails... )
SecurityAgentAssignment ( PartyId, AgentId, fromTime, untilTime )
ご覧のとおり、パーティーには複数のテント、ピエロ、警備員を割り当てることができます。
現在、パーティー プランナーは、同じタイプのパーティーを計画することがよくあります。ほとんどの場合、テントは 1 つ、ピエロは 1 つ、セキュリティはありません。しかし、3 つのテントがあり、ピエロがなく、3 人のセキュリティ エージェントがパーティーに参加する、別の一般的なタイプのパーティーもあります。彼らは、「プリセット」(「パーティー パッケージ」または「パーティー テンプレート」とも呼ばれます) を保存できるようにしたいと考えています。これを選択すると、データベースに必要なテント、ピエロ、およびセキュリティの行が追加されます。もちろん、パーティーは通常どおりカスタマイズできますが、これは最初のデータ入力を最小限に抑えるための手段にすぎません。
問題は、これをどのように実装するかです。
最も簡単な方法は、Tents
、Clowns
、およびテーブルのコピーを作成し、次のようSecurityAgentAssignment
に新しいテーブルを追加することです。Packages
Packages ( PackageId, Name )
Package_Tents ( PackageId, TentDetails... )
Package_Clowns ( PackageId, ClownDetails... )
Package_Security ( PackageId, AgentId )
その後、ビジネス ロジックはTent
行から行を作成する必要があります。2 つのスキーマが異なるため (たとえば、andフィールドがないなど) Package_Tent
、ステートメントでは実行できません。INSERT INTO SELECT FROM
Package_Security
fromTime
untilTime
このアプローチはシンプルで機能しますが、いくつかの問題があります。
- これは、Package システムのためだけにテーブルの負荷を複製することを意味します。これが、プロジェクトがテーブル肥大化する方法です。
- 元のテーブルを変更すると、これらも変更する必要があります。
- なんとなく「間違っている」ようです。
2 番目のアプローチは、既存のテーブルを使用することですが、次のように 1 つの新しいテーブルを追加します。
Packages ( PackageId, Name, PartyId )
このPackages
テーブルは、既存のParty
行 (および関連するテント、ピエロ、およびセキュリティの行) にリンクしています。リンク先のパーティーは存在しません (または、その詳細は重要ではありません)。新しいパーティーのテンプレートになり、別のテーブルから新しいテーブルに行を作成するのではなく、単一のテーブルで行を複製するだけです。テーブル。このアプローチには、別の GUI ツール/領域を用意するのではなく、ユーザーが既存の GUI を使用してパッケージをプロトタイプ パーティとして変更できるという利点もあります。
Packages
ただし、「不純物」に悩まされています。「パーティテンプレート」ではなく「パーティ」としてのパーティの状態が、テーブル内の外部キーであるかどうかに依存するようになりました。また、無効または無意味なデータが存在することも意味します (たとえば、パーティ テンプレートにセキュリティのfromTime
とがあるのは意味がありません)。untilTime
StackOverflow は 1 つのアプローチを他のアプローチよりも優先しますか、それとも 3 つ目の方法がありますか?