Re: [GENERAL] scheduling table design
От | davidb@vectormath.com |
---|---|
Тема | Re: [GENERAL] scheduling table design |
Дата | |
Msg-id | 002c01bf7fb4$27b86520$0602010a@bullwinkle.vectormath обсуждение исходный текст |
Список | pgsql-general |
I didn't say you could write a good application. David Boerwinkle -----Original Message----- From: Ed Loehr <eloehr@austin.rr.com> To: davidb@vectormath.com <davidb@vectormath.com> Cc: kaiq@realtyideas.com <kaiq@realtyideas.com>; Barnes <aardvark@ibm.net>; pgsql-general@postgreSQL.org <pgsql-general@postgreSQL.org> Date: Friday, February 25, 2000 10:51 AM Subject: Re: [GENERAL] scheduling table design >davidb@vectormath.com wrote: >> >> The advantage of (3) is that it would be extremely easy to write an >> application around. However, the inflexibility of it makes my stomach >> tighten. I agree with kaiq, I think you're making a mistake. > >Hmmm. What would a SQL query look like in (3) that finds all >appointments for a person? > >Cheers, >Ed Loehr > >> >> 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?
В списке pgsql-general по дате отправления: