I didn't say you could write a good application.
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>;
Date: Friday, February 25, 2000 10:51 AM
Subject: Re: [GENERAL] scheduling table design
>> 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?
>> >> I was previously thinking that I needed to do something like creating
>> >> following table:
>> >> 3) date | doctor | 0800 | 0815 | 0830 | 0845 | 0900 ....and so on
>> >> minutes
>> >> where each time slot holds a reference# to an appointment database
>> >> reference# | patient_id# | reasonfor_app | kept_app | authorized
>> >> Assuming I am summarizing 1) and 2) correctly-the way you
>> >> two have already explained the advantages and disadvantages of each of
>> >> solutions compared to one another. 3) however, is fundamentally
>> >> in that time is a field name instead of an actual field. It is
>> >> timewise, but does it offer any advantages such as speed or simplicity
>> >> the SQL searches? Has 3) ever been done, or is it seriously flawed
>> >> Are there other solutions?
pgsql-general by date
|Next:||From: Karl DeBisschop||Date: 2000-02-25 19:26:48|
|Subject: Re: [GENERAL] Re: [HACKERS] TRANSACTIONS|
|Previous:||From: kaiq||Date: 2000-02-25 16:58:38|
|Subject: Re: [GENERAL] scheduling table design|