RE: [GENERAL] scheduling table design
От | Barnes |
---|---|
Тема | RE: [GENERAL] scheduling table design |
Дата | |
Msg-id | 000001bf7f9c$9b1df240$0a64a8c0@fries обсуждение исходный текст |
Ответ на | Re: [GENERAL] scheduling table design (<kaiq@realtyideas.com>) |
Ответы |
RE: [GENERAL] scheduling table design
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: