From: | Ed Loehr <eloehr(at)austin(dot)rr(dot)com> |
---|---|
To: | davidb(at)vectormath(dot)com |
Cc: | kaiq(at)realtyideas(dot)com, Barnes <aardvark(at)ibm(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [GENERAL] scheduling table design |
Date: | 2000-02-25 16:54:14 |
Message-ID: | 38B6B3B6.9AB142F0@austin.rr.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
davidb(at)vectormath(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | kaiq | 2000-02-25 16:58:38 | Re: [GENERAL] scheduling table design |
Previous Message | davidb | 2000-02-25 16:08:07 | Re: [GENERAL] scheduling table design |