医師がシフトをスケジュールするときに、各時間帯で予約できる人数をカスタマイズできます。もちろん、ここでの時間帯もカスタマイズできます。 8:00-9:00....17:00-18:00 のように、1日8時間を8つの時間帯に分けます。シフト勤務は月曜日から日曜日までです。誰か具体的なアイデアを教えていただけますか?
まず、段落と各段落で選択できる最大人数を使用するか、表を使用します。
たとえば、各セグメントは 20 人までしか収容できません。
$t = array(
array('08:00', '09:00', 20),
....
.....
array('17:00', '18:00', 20),
);
次に、人物を識別するためのテーブルを使用します。おおよそのフィールドは次のとおりです。
id 再利用するかどうかを確認します。
date Date
t ??Page??、??
num ??person? も使用できます。チェックが入っている場合はチェックを入れてください。
たとえば、ユーザーが 8:00 ~ 9:00 の時間帯にいる場合、時間を確認できます。
select num from table where date='2014-06-10' and t=0;
返された num が 20 未満の場合は、? を挿入します。
キャンセル機能を追加したい場合は、9:00の10分前からキャンセルができないように設定することもできます。一般的な考え方は??です。
月曜日と日曜日の待ち時間が異なる可能性がある場合、$t????? を週のキーとしてさらに 1 つに分割します。データベースの場合は、管理を容易にするためにデータベースを作成します。
'MON' =>array(
:00', '18:00', 20),
),
'TUE' => array(
)
);最初にデータベース、テーブルドクター(医師)、テーブルオーダー(予約)、テーブルワーク(スケジュール)を設計します
予約番号が生成されるたびに、最初にスケジュールが取得されます。その日のスケジュールが作成されていない場合は、最初にスケジュールを作成します。 。
シフトスケジュール用に追加のスケジュールを作成する場合は、設定を手動で変更できます。
上記の内容は理にかなっていますが、医師がその日のその時間に出勤することを保証することはできません。特定の状況下では出勤しない場合や、何らかの理由で遅れる可能性があります
したがって、それをプログラムに書き込むことはできません。
学びましょう〜
まず、段落と各段落に分割できる最大人数を使用するか、表を使用します。
$t = array(
array('08:00', '09:00', 20),
.....
array('17:00', '18:00', 20),);
次に、人物を識別するためのテーブルを使用します。おおよそのフィールドは次のとおりです。
id 再利用するかどうかを確認します。
date Date
t ??Page??、??
num ??person? も使用できます。チェックが入っている場合はチェックを入れてください。
たとえば、ユーザーが 8:00 ~ 9:00 の時間帯にいる場合、時間を確認できます。
select num from table where date='2014-06-10' and t=0;
返された num が 20 未満の場合は、? を挿入します。
キャンセル機能を追加したい場合は、9:00の10分前からキャンセルができないように設定することもできます。一般的な考え方は??です。
ちょっと混乱していて、何を言っているのかよくわかりません
LZ は 3 階のプランをご利用ください。実際、必要なのは、どの医師が対応可能か、スケジュール、予約状況を調べることだけです。データベース操作を使用すると、より柔軟になります。
複雑なので管理しやすいようにデータテーブルを使用します
データテーブルの構造は以下の通りです:
医師の情報を記録するdoctorテーブル
Doctor_id 医師ID PK
name 医師名
timeline table 、各医師を記録します。 1 日の期間ごとに予約できる情報は、定期的に追加および削除する必要があり、新しい日付の予約時間を追加したり、期限切れのものを削除したりする必要があるため、週は役に立ちません。日付を直接使用して決定します。
tid タイムライン PK
Doctor_id 医師 ID FK
date 割り当て 予約を許可される人数
starttime 開始時刻 例 8:00
end time 期間の終了 例 9:00
status この期間中に予約が許可されているかどうか0 いいえ 1 許可
注文予約フォーム、ユーザーの予約状況を記録します order_id 予約 ID PK
userid ユーザー ID -> 会員システム、この FK が必要です
予約された期間の tid ID
プロセス:
まず、次のように医師とタイムラインのデータを入力します 医師は 2 人います
Doctor_id name
1 d1
2 d2
2014-06-11 のスケジュールでは、doctor1 には 8 つのフルタイムスロットがあり、doctor2 には 6 つのフルタイムスロットしかありません一定期間内に作業する必要があります
tid Doctor_id date date 割り当て starttime endtime status
1 1 2014-06-11 10 08:00 09:00 1
2 1 2 014-06-11 10 09:00 10:00 1
3 1 2014-06-11 10 10:00 11:00 1
4 1 2014-06-11 12 11:00 12:00 1
5 1 201 4-06-11 12 14:00 15:00 1
6 1 2014-06-11 8 15:00 16:00 1
7 1 2014-06-11 10 16:00 17:00 1
8 1 2014-06-11 5 17:00 18:00 1
9 2 2014-06-11 10 08:00 09:00 1
10 2 2014-06-11 10 09:00 10:00 1
11 2 2014-06-11 10 10:00 11:00 1
12 2 2014-06-11 12 14:00 15:00 1
13 2 2014-06-11 10 16:00 17:00 1
14 2 2014-06-11 5 17:00 18:00 1予約
最初のユーザー useid=1 は、2014-06-11 11:00~12:00 Doctor1 の予約を希望しています
まずタイムラインを決定します Doctor_id=1 date=2014-06-11 starttime=11:00 endtie=12 :00クォータ>0のレコードが存在するかどうか
存在しない場合は、予約期間がないか、クォータがいっぱいであることを示すプロンプトを返します
存在する場合
1. order テーブルに新しいレコードを追加します
order_id userid tid
1 1 1 4 2014-06-09 10:29:29
2. タイムライン tid=4 をuota-1 に設定すると、レコードは
4 1 2014 になります。 -06-11 11 11:00 12:00 1
これはプロセスです。非常に明確であるはずです。
皆さん、これを読むのが耐えられません。最近出張に行って、昨日戻ってきました。この場合、毎回新しいアイテムを追加する必要があります。データが週に基づいている場合は、毎週更新されます。時間が死ぬほど書かれているようです
皆さん、最近出張に行って昨日帰ってきたところですが、この場合、私はやらなければなりません。毎回新しい項目を追加し、データを手動で入力します。週ベースで計算される場合は、毎週更新されます。時間は死に至るまで書かれているようです
??いいえ、死んでいます。仕事が必要な場合はスケジュールに追加されます。
一体何がしたいのですか?まずは自分の考えをクリアにしてください!
「予約」していませんか?どうして毎週同じことがあり得るのでしょうか?
皆さん、これを読むのが耐えられません。最近出張に行って、昨日戻ってきたところです。この場合、新しいアイテムを追加する必要があります。週ごとにデータを手動で追加すると、週に 1 回更新されます。時間は死に至るまで書かれているようです
??いいえ、死んでいます。仕事が必要な場合はスケジュールに追加されます。
最初はこれを 1 日 1 回実行し、終了したら 7 日サイクルに変更することもできます。
このような方法で理解できますか? , これは7日間の自動サイクルで、期間や1日あたりの人数はカスタマイズされているのですが、このSQL文はどうやって書けばいいのでしょうか?申し訳ありませんが、お客様は当初のアイデアにご満足いただけなかったので、フェイがこのように作成しました フィールドは次のとおりです:
日付、専門家、期間 1、期間 2...期間 10
つまり、専門家ごとに 1 つのレコードです1 日あたり
フィールドは次のとおりです:
日付、エキスパート、期間 1、期間 2...期間 10
つまり、各エキスパートには 1 日あたり 1 つのレコードがあります
なぜ?
フォーム (#14 のスクリーンショット) に毎日を記録として保存するだけです
フォームが 1 週間に設定されている場合は、送信後、1 日あたり 7 レコードとして保存するだけです
なぜですか?
フォーム (#14 のスクリーンショット) に毎日をレコードとして保存するだけです
フォームが 1 週間に設定されている場合は、送信後、1 日ごとに 7 レコードとして保存するだけです
まず、個人情報やその他の情報に注目する必要があります。段落の情報と段落の権限は、各ユーザー自身によって設定されるか、システムによって設定されます
ユーザー自身によって設定される場合は、それを確認できます
まず、セグメントを含む構成情報テーブルがあります。 、8.00、9.00、または 8.30、9.00、9.30 などの半分のセグメントです。各セグメントは 1 つのセグメントです
次に、教師はこれらすべてのイベントを設定ウィンドウにリストし、時間帯を決定します。
患者は情報画面を見て、ホーム設定と関連情報を入力します。
最初に考えるべきことは、これらの段落と段落の権限、人物、またはその他の情報が各ユーザーによって設定されるか、各ユーザーによって設定される場合は、次のとおりです。はい??
まず、8.00、9.00、または 8.30、9.00、9.30 などの 30 分セグメントを含む構成情報テーブルがあります。各セグメントは 1 つです ???
次に、教師がこれらをすべてリストします。設定でイベントを選択し、学生は許可される出席時間である時間帯を決定します
情報が設定されるのを待ってから入力します。
患者は情報画面を確認します。過去 7 日間のホームページ設定と関連情報を入力します。これはシステムによって設定されます。保険が完了していない場合は、医師が独自にシフトを調整します。
Period 2
送信後、すべてが一致しませんか?
mysqli または pdo 拡張機能を使用している場合は、オーバーヘッドなしでパラメーターをバインドしてループに挿入できます。
のために、コマンド文字列を組み立てるのは難しくありません。システムの互換性を考慮して、毎日時間帯ごとに個別の設定をセットアップし、データベースに保存することをお勧めします。
入力ボックスの名前が次の場合:
期間 1Period 2