0

RDBMSで、いくつかの提案された時間がある会議をモデル化することを検討していますが、1つが承認済みまたは主要なものとして選択されます。何かのようなもの：

create table Meeting ( meetingId int );
create table ProposedTime( meetingId int, dateAndTime datetime );

ただし、ユーザーが提案された時間の1つを選択できるインターフェイスがあり、その選択を保存する必要があります。

私は2つのオプションを考えることができますが、それぞれに欠点があります。

  1. 選択した提案を会議テーブルに保持します。

    create table Meeting( meetingId int, selectedProposalId int );
create table ProposedTime( proposalId int PK, meetingId int, dateAndTime datetime );

    このアプローチでは、selectedProposalIdが別の会議に属するプロポーザル用である可能性があります。

  2. 選択したプロポーザルにフラグを保存します。

    create table Meeting(meetingId int);
create table ProposedTime( meetingId int, dateAndTime datetime, isSelected bool );

    このアプローチでは、2つの提案に選択済みのマークを付けることができます。

整合性を確保するための「ハック」があることは知っていますが（2の場合、MS SQLでは、フィルターされた一意のインデックスを使用して、1つだけが選択されるようにすることができます）、ベンダー固有のコードにはコミットしません。

また、アプリケーション層で正確さを強制するだけでも問題ありませんが、それでも両方のオプションが開いたままになります。

何をお勧めしますか？誰かが何かアイデアを持っているなら、私は他のオプションも開いています;）

注：私はRails 3を使用しているので、ActiveRecordでこれを処理するための好ましい方法がある場合は、それを聞きたいと思います。

4

1 に答える 1

1

素晴らしい質問です。私はあなたが潜在的な矛盾を評価しているという事実が大好きです。この場合、最初の解決策は正しいものであり、わずかな変更が1つあります。ProposedTimeの主キーはmeetingIdを含む複合主キーである必要があります。

これにはいくつかの理由があります。まず、proposedTimeは会議なしでは明らかに存在できず、さらに重要なことに、特定の会議なしでは存在できません。基本的に、proposedTimeは会議のコンテキストを除いて定義できないため、その定義によってスタンドアロンにすることはできません。

次に、この依存関係は、meetingIdを必須属性として十分に表現されていません。たとえば、proposedTimeのmeetingIdフィールドを更新しても意味がありません。「午前9時を別の会議に移動しましょう！」更新された主キーは本質的に異なるものであるため、meetingIdを主キーの一部にすることは、この種の無意味な更新を明示的に阻止します。

最後に、proposedTimeに論理的に不完全なキーがあるという事実は、それを適切に使用しようとしたときに最初に遭遇したことの1つです。すべてのデータベース関係は、理想的には、宣言的に一貫している必要があります。つまり、「ライオンには2人の親がいる」という関係を表現できれば、1人の親がリスになることは不可能なはずです。明らかに、パフォーマンスとプラットフォームの制限は、常にその目標を達成できるとは限らないことを意味しますが、そのような不一致は、さらなる調査が必要な「コードの臭い」と見なすことができます。あなたの場合、修正は小さくてパフォーマンスが良いようです。

tl; dr：proposedTimeのPKにmeetingIdを追加し、最初のソリューションを使用します。

于 2011-04-28T20:04:54.000 に答える