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?
