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?
