Re: [GENERAL] scheduling table design

I didn't say you could write a good application.

David Boerwinkle
-----Original Message-----
From: Ed Loehr <eloehr(at)austin(dot)rr(dot)com>
To: davidb(at)vectormath(dot)com <davidb(at)vectormath(dot)com>
Cc: kaiq(at)realtyideas(dot)com <kaiq(at)realtyideas(dot)com>; Barnes <aardvark(at)ibm(dot)net>;
pgsql-general(at)postgreSQL(dot)org <pgsql-general(at)postgreSQL(dot)org>
Date: Friday, February 25, 2000 10:51 AM
Subject: Re: [GENERAL] scheduling table design

>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?