First, let me start off by thanking you two for the design ideas. You've
been very helpful, as have Ed and Omid who focused more on laying the
groundwork for approaching the problem.
Maybe I'm overcomplicating things. You both seem to be suggesting a table
something like:
1) date | doctor | time | patient_id# | reasonfor_app | kept_app |
authorized
with David's variation of putting the doctor and time information in a
separate table so that I might have two tables:
2) date | time_doc_link | patient_id# | reasonfor_app | kept_app |
authorized
and
time_doc_link | time | doctor | active_flag
I was previously thinking that I needed to do something like creating the
following table:
3) date | doctor | 0800 | 0815 | 0830 | 0845 | 0900 ....and so on every 15
minutes
where each time slot holds a reference# to an appointment database such as:
reference# | patient_id# | reasonfor_app | kept_app | authorized
Assuming I am summarizing 1) and 2) correctly-the way you suggested-then you
two have already explained the advantages and disadvantages of each of those
solutions compared to one another. 3) however, is fundamentally different
in that time is a field name instead of an actual field. It is inflexible
timewise, but does it offer any advantages such as speed or simplicity in
the SQL searches? Has 3) ever been done, or is it seriously flawed somehow?
Are there other solutions?
Thank you again.
David Barnes
aardvark@ibm.net
