Re: [GENERAL] scheduling table design

there are two issues here: one is the html(or applet) gui, another is
the database. I was talking about the latter. but seems you also on
the former?
for gui: I also setup a minimal time granularity because I do not
want the user to type in, I only let them click -- I hate javascript
and I hate junk data. However, the database and scheduling
manipulation algorithm do not require minimal granularity (I hope
the system can be used longer and broader).

for database: batch-extending is only needed for cycling scheduling.
e.g., if someone schedule Every WeekEnd for the high-end hotel (good
life!). then, the program can only put finite number of appointments
(events, schedules, whatever name you like) in the database. I choose to
do it for example two years. OOPS, I found a design bug!!!!! It surly
affect other scheduling also. however, it is not related with gui.

On Thu, 24 Feb 2000 davidb(at)vectormath(dot)com wrote:

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