2

このような状況に最適な解決策/実践は何ですか？複数のテーブル（オブジェクト）を参照できるテーブルがありますか？

これは、テーブルUserCalendarの例です。これは、ユーザーがイベントを保存するテーブルですが、システムはこのテーブルに後ろから挿入します。ユーザーは期限のあるいくつかのサービスを実行し、それらもこのテーブルに挿入されます。問題は、UserEventテーブルのようなテーブルがないことです。ユーザーは、説明としてこのカレンダーにすべてのイベントを保存する必要があります。これをできるだけ単純にする必要があります。

これは2つの方法で設計できます。

1）

UserCalendar
UserCalendarId | UserId | 説明| ObjectType | ObjectId

このオプションを使用すると、このテーブルをFKする必要はありません。ObjectType（Notification、Service、Calendar）を変更し、そのテーブルのIDをObjectIdとして使用することしかできませんでした。イベントの場合、そのようなテーブルはなく、これはnullフィールドになります。これを疑似FK列と呼びます。

2）または、理論的には、FKごとに複数のテーブルを使用して使用することもできます。

UserCalendar
UserCalendarId | UserId | 説明

UserEventUserCalendarId
| EventId

UserServices
UserCalendarId | ServiceId

UserNotifications
UserCalendarId |NotificationId
..。

この外部関係テーブルは、各システムイベントまたは特定のタイプに属するその他のカスタムイベントの数値にすることができます

最初の解決策は、迅速な実装です。

4

1 に答える 1

2

2つのデザインを組み合わせた3番目のソリューションをお勧めします。

UserCalendar
UserCalendarId | UserId | 説明

UserCalendarAttributes
UserCalendarId | ObjectType | ObjectId

このようにして、カレンダーエントリに必要な数の追加の参照（イベントや通知など）を自由に追加でき、UserCalendarテーブルと他のテーブルの間に緊密な結合がありません。

また、FKをメインのUserCalendarテーブルに配置することが理にかなっている場合は、その追加データ（イベント、サービスなど）にアクセスする必要がある頻度にも少し依存します。

スキーマの複雑さは少し増しますが、パフォーマンスよりも柔軟性を重視することをお勧めします。パフォーマンスの問題に見舞われるよりも、機能要件が変更される可能性が高くなります。

于 2011-04-06T12:18:33.963 に答える