0

私が取り組んでいるデータ モデルについていくつか質問があります。

もう少し詳細な予定管理システム用です。予定ごとに、多くの詳細を取得する必要があります。

アプローチ 1:-

1 つのテーブル内のすべてのフィールド。

田畑 ：-

1. appointment_id
2. doctor_id
3. client_id
4. appointment_type
5. start_time
6. end_time
7. notes
8. weight
9. weight_unit
10. temperature
11.temperature_unit
12.heart_rate
13.respiratory_rate
14.pulse_rate
15.hydration
16.systolic_bp
17.diastolic_bp
18.body_condition_code
19.pain_score
20.general_appearance
21.general_appearance_status
22.oral_health
23.oral_health_status   
24.eyes_health
25.eyes_health_status   
26.ears_health
27.ears_health_status   
28.lungs_health
29.lungs_health_status
....
....
...
 status
 created_by
 created_time
 updated_by
 updated_time

アプローチ 2:-

別表の予約とその他の詳細

2つの独立したテーブル

表 1:- 予定

1. appointment_id
2. doctor_id
3. client_id
4. appointment_type
5. start_time
6. end_time
7. notes
8. status
9. created_by
10. created_time
11.updated_by
12.updated_time

表 2:- Appointment_details

1. appointment_id
2. doctor_id
3. client_id
4. weight
5. weight_unit
6. temperature
7.temperature_unit
8.heart_rate
9.respiratory_rate
10.pulse_rate
11.hydration
12.systolic_bp
13.diastolic_bp
14.body_condition_code
15.pain_score
16.general_appearance
17.general_appearance_status
18.oral_health
19.oral_health_status   
20.eyes_health
21.eyes_health_status   
22.ears_health
23.ears_health_status   
24.lungs_health
25.lungs_health_status
....
....
...
 status
 created_by
 created_time
 updated_by
 updated_time

アプローチ 3:-

予約、予約の必需品、その他の詳細は別の表に記載

3つの独立したテーブル

表 1:- 予定

1. appointment_id
2. doctor_id
3. client_id
4. appointment_type
5. start_time
6. end_time
7. notes
8. status
9. created_by
10. created_time
11.updated_by
12.updated_time

表 2:- Appointment_essentials

1. appointment_id
2. doctor_id
3. client_id
4. weight
5. weight_unit
6. temperature
7.temperature_unit
8.heart_rate
9.respiratory_rate
10.pulse_rate
11.hydration
12.systolic_bp
13.diastolic_bp
14.body_condition_code
15.pain_score

表 3:- Appointment_details

    1. appointment_id
    2. doctor_id
    3. doctor_id
    4.general_appearance
    5.general_appearance_status
    6.oral_health
    7.oral_health_status   
    8.eyes_health
    9.eyes_health_status   
   10.ears_health
   11.ears_health_status   
   12.lungs_health
   13.lungs_health_status
    ....
    ....
    ...
     status
     created_by
     created_time
     updated_by
     updated_time

アプローチ 4:-

予約、予約の必需品、Health_Parts_Prop および Health_Prop_Mapping

4 つの独立したテーブル

表 1:- 予定

1. appointment_id
2. doctor_id
3. client_id
4. appointment_type
5. start_time
6. end_time
7. notes
8. status
9. created_by
10. created_time
11.updated_by
12.updated_time

表 2:- Appointment_essentials

1. appointment_id
2. doctor_id
3. client_id
4. weight
5. weight_unit
6. temperature
7.temperature_unit
8.heart_rate
9.respiratory_rate
10.pulse_rate
11.hydration
12.systolic_bp
13.diastolic_bp
14.body_condition_code
15.pain_score

表 3:- health_part

1. health_part_id
2. health_part_name
3. health_part_status_id
4. created_by
5. created_time
6. updated_by
7. updated_time

表 3:- appt_health_part_mapping

 1. appt_id
   2. client_id
   4. health_part_id
   5. health_part_status_id
   6. value
   7. created_time

ユースケース:-

  1. 医師、クライアント、予約時間、メモなどの詳細を含む予約を保存する画面
  2. ログインしている医師の週間カレンダーで予約を表示する画面
  3. その日の今後の予定の画面
  4. すべての観察のように、予約後にすべての詳細を保存する画面

そのため、予定中に、すべての予定のためにキャプチャする必要がある必需品はほとんどありません。また、予約、目と耳、肺と耳の予約など、予約に基づく詳細はほとんどありません。現在、システムはいくつかのパーツをキャプチャしており、将来変更される可能性があります。

したがって、上記のすべての事実を考慮して、最終的なアプローチを採用することにしました。

これについて何か考えはありますか？

また、生まれたときからの体重の傾向と身長の傾向を示す必要があるかもしれません。

現在のデザインで十分ですか？

4

0 に答える 0