1

パーティー プランナーが使用するソフトウェアを作成しているとします。これは、現在のデータベース スキーマがどのように見えるかです。

Parties ( PartyId, ClientId, DateTime )
Tents ( PartyId, TentDetails... )
Clowns ( PartyId, ClownDetails... )
SecurityAgentAssignment ( PartyId, AgentId, fromTime, untilTime )

ご覧のとおり、パーティーには複数のテント、ピエロ、警備員を割り当てることができます。

現在、パーティー プランナーは、同じタイプのパーティーを計画することがよくあります。ほとんどの場合、テントは 1 つ、ピエロは 1 つ、セキュリティはありません。しかし、3 つのテントがあり、ピエロがなく、3 人のセキュリティ エージェントがパーティーに参加する、別の一般的なタイプのパーティーもあります。彼らは、「プリセット」(「パーティー パッケージ」または「パーティー テンプレート」とも呼ばれます) を保存できるようにしたいと考えています。これを選択すると、データベースに必要なテント、ピエロ、およびセキュリティの行が追加されます。もちろん、パーティーは通常どおりカスタマイズできますが、これは最初のデータ入力を最小限に抑えるための手段にすぎません。

問題は、これをどのように実装するかです。

最も簡単な方法は、TentsClowns、およびテーブルのコピーを作成し、次のよう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 FROMPackage_SecurityfromTimeuntilTime

このアプローチはシンプルで機能しますが、いくつかの問題があります。

  1. これは、Package システムのためだけにテーブルの負荷を複製することを意味します。これが、プロジェクトがテーブル肥大化する方法です。
  2. 元のテーブルを変更すると、これらも変更する必要があります。
  3. なんとなく「間違っている」ようです。

2 番目のアプローチは、既存のテーブルを使用することですが、次のように 1 つの新しいテーブルを追加します。

Packages ( PackageId, Name, PartyId )

このPackagesテーブルは、既存のParty行 (および関連するテント、ピエロ、およびセキュリティの行) にリンクしています。リンク先のパーティーは存在しません (または、その詳細は重要ではありません)。新しいパーティーのテンプレートになり、別のテーブルから新しいテーブルに行を作成するのではなく、単一のテーブルで行を複製するだけです。テーブル。このアプローチには、別の GUI ツール/領域を用意するのではなく、ユーザーが既存の GUI を使用してパッケージをプロトタイプ パーティとして変更できるという利点もあります。

Packagesただし、「不純物」に悩まされています。「パーティテンプレート」ではなく「パーティ」としてのパーティの状態が、テーブル内の外部キーであるかどうかに依存するようになりました。また、無効または無意味なデータが存在することも意味します (たとえば、パーティ テンプレートにセキュリティのfromTimeとがあるのは意味がありません)。untilTime

StackOverflow は 1 つのアプローチを他のアプローチよりも優先しますか、それとも 3 つ目の方法がありますか?

4

2 に答える 2

1

2番目のアプローチを使用することは間違いなく理にかなっています。すべての設計には長所と短所がありますが、2 番目のアプローチ (スキーマと GUI を再利用する) の利点は、どんな些細な懸念よりもはるかに重要です。

個人的には、あなたが言及した問題はスキーマの「不純物」とは見なされません。むしろ、アプリケーションで明示する必要があるビジネス上の制約です。たとえば、次のようになります。

  • パーティ テンプレートを編集する場合は、 と を無視fromTimeuntilTime、GUI でこれらを非表示にします
  • 通常のパーティーを編集する場合は、fromTimeuntilTimeが有効であることを確認してください
于 2012-09-06T06:00:16.197 に答える
0

私の見方では、テンプレートはまさにテンプレート、つまりプリセットです。プリセット値を xml として保存できます。テーブル構造を壊さずにテンプレートを変更する範囲が広く、実行時に xml の解析と変換を処理する必要があるのはアプリ コードだけです。ここでの唯一の欠点は、テンプレートが大きくなりすぎると xml が管理できなくなる可能性があることです。ただし、中小規模の使用と効果的な DAO/ORM レイヤーの場合、構成は ) でうまく機能します Party_Template(template_id,template_title,template_desc

于 2012-09-08T00:01:09.103 に答える