Re: [GENERAL] scheduling table design

Hi kaiq,

You asked:
>it is a good idea. but why it is really necessary?

As you guessed, we chose this approach to keep from having to batch extend
the data table. Batch extending the table would not have worked for this
project for two reasons:
1) The application tracked reservations at expensive restaurants. Most
reservations were for one to two weeks in advance, but they could be for as
much as a year and a half in advance. I had not considered the possibility
of dynamically extending the data table.
2) Ordinarily only a small percentage of the available items (tables at the
restaurants) were reserved. The restaurants liked this because they wanted
to maintain an uncrowded atmosphere. However, this meant that batch
extending (or even dynamically extending) would create a large percentage of
records that were never used.

I have to decided to add a third reason:
3) Batch extending would not allow overloading of appointments.

David Boerwinkle

-----Original Message-----
From: kaiq(at)realtyideas(dot)com <kaiq(at)realtyideas(dot)com>
To: davidb(at)vectormath(dot)com <davidb(at)vectormath(dot)com>
Cc: Barnes <aardvark(at)ibm(dot)net>; pgsql-general(at)postgreSQL(dot)org
<pgsql-general(at)postgreSQL(dot)org>
Date: Thursday, February 24, 2000 9:56 AM
Subject: Re: [GENERAL] scheduling table design

>
>
>On Wed, 23 Feb 2000 davidb(at)vectormath(dot)com wrote:
>
>> Hello Mr. Barnes,
>>
>> I don't know of a nice solution to the problem of scheduling events that
may
>> occur indeterminately far into the future. The way I have solved this
>why you need that? cycling scheduling? -- that is my "issue" also. For
>cycling scheduling, I have to set a limit. I'm considering a subroutine to
>automatically batch-extend the limit. And, the third step is add a
>subroutine to kind of sense the need to extend the limit Dynamically (not
>only batch-extend) -- that is much more difficult, and I do not really
>plan to do that ;-)
>> problem before is to have a table of available items. In this case the
>> available items would be something like:
>> 1 9:00 Dr. Jones
>> 2 9:30 Dr. Jones
>> 3 10:00 Dr. Jones
>> .
>> .
>> .
>> 17 9:00 Dr. Smith
>> 18 9:30 Dr. Smith
>> 19 10:00 Dr. Smith
>> etc.
>> This serves as the control table.
>nice.
>
>> One problem with this solution is that your client will have to settle on
a
>> minimum granularity for appointment times. That is, does he have
>> appointments every half hour, or every fifteen minutes?
>it is a good idea. but why it is really necessary?
>
>