Re: [GENERAL] scheduling table design

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?

In response to

Browse pgsql-general by date

  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