0

私はそのようなテーブルを持っています:

CREATE TABLE `Appointment` (
    id INT NOT NULL AUTO_INCREMENT,
    user_id INT NOT NULL,
    doctor_slot_id INT NOT NULL,
    date DATE NOT NULL,
    PRIMARY KEY(id),
    FOREIGN KEY(user_id) REFERENCES user(id),
    FOREIGN KEY(doctor_slot_id) REFERENCES doctor_slot(id)
);

ユーザーが 1 日に 1 回しか医師の診察を受けられないようにしたいと考えています。したがって、doctor_id と user_id の間に一意の制約を追加したいのですが、この構造ではできません。SQL構文にないものを試しました：

UNIQUE(user_id, doctor_slot.doctor_id)

と

UNIQUE(user_id, doctor_slot(doctor_id))

と

UNIQUE(user_id, doctor_id(doctor_slot))

しかし、ご存知のように、それらは機能しませんでした。何か提案はありますか？

4

1 に答える 1

0

doctor_slot とは何かについてのコメントに基づいて、スキーマの設計に少し問題があるようです。予約テーブルに slot_id と日付の両方を格納する理由はありません。ドクタースロットには既に日付コンポーネントが含まれているため、予約テーブルに日付を格納することはデータの冗長ストレージであり、問​​題が発生する可能性があります。同期を保ちます。

もちろん、このテーブルの日付がなければ、このテーブルのデータベースに一意の制約を強制することはできません。

このようなカレンダー ベースのアプリに対する私の推奨事項は、最初に日付テーブルを作成することです。私は通常、 http ://www.dwhworld.com/2010/08/date-dimension-sql-scripts-mysql/ のようなスクリプトを使用して、 この日付テーブルを作成します。このようなテーブルを使用すると、単純な date_id を使用して、日付に関するあらゆる種類のさまざまな情報を参照できます (これは、データ ウェアハウスで一般的に使用される手法です)。日付が必要な他のすべてのテーブルでこの date_id を使用している限り、任意の方法 (曜日、月、週番号、平日かどうかなど) で日付を簡単に調べることができます。 .)。

同様の概念を使用して、タイムスロットを構築できます。おそらく、15 分の間隔を表す 96 エントリ (24 時間 * 15 分) を持つテーブルを作成します。もちろん、これは好きな間隔に変更できます。

次に、次のように予約テーブルを作成できます。

appointment_id
user_id
doctor_id
date_id
time_start_id <= time slot for appointment start
time_end_id <= time slot for appointment end

ここでは、doctor_slots テーブルが別途必要になるとは思いません。開いている医師のスロットを追跡したい場合は、スロットがいっぱいになるまで user_id を単純に = NULL にすることで、このテーブルでそれを行うこともできます。

これにより、user_id と date_id に一意のインデックスを適用できます。

于 2013-05-14T21:26:38.207 に答える