Re: [GENERAL] scheduling table design - Mailing list pgsql-general
From | |
---|---|
Subject | Re: [GENERAL] scheduling table design |
Date | |
Msg-id | Pine.LNX.4.10.10002241138490.17365-100000@picasso.realtyideas.com Whole thread Raw |
In response to | Re: [GENERAL] scheduling table design (davidb@vectormath.com) |
Responses |
RE: [GENERAL] scheduling table design
("Barnes" <aardvark@ibm.net>)
|
List | pgsql-general |
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@vectormath.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@realtyideas.com <kaiq@realtyideas.com> > To: davidb@vectormath.com <davidb@vectormath.com> > Cc: Barnes <aardvark@ibm.net>; pgsql-general@postgreSQL.org > <pgsql-general@postgreSQL.org> > Date: Thursday, February 24, 2000 9:56 AM > Subject: Re: [GENERAL] scheduling table design > > > > > > > >On Wed, 23 Feb 2000 davidb@vectormath.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? > > > > >
pgsql-general by date: