Hello, some thoughts about this task:
* I wrote my first "agenda" for incoming touristic agency about 8 years ago, first version in FileMaker btw, and do several more "agenda" solutions for other touristic needs on more professional system. But on most of the systems it was a real pain to get all the systems up and running with a usable speed. Optimization of the data structure was obvious necessary and results most of the times in the suggested methods, e.g. create predefined slots, create "empty" years, ...
But NOW in these days most actual machines are fast enough to not need these "tricks" speed wise. Even the old FileMaker application, still in real use, just flys on a G5 iMac. So check it out, before start with this "bad" optimizations.
* Perhaps just scheduling for one doc is just another story, than scheduling for several hundred hotels, with 1000s of rooms, BUT my experience is: If you start using the above mentioned methods, write all possible reorganization tools before writing the application, you will need it, sooner or later!
And start imagine all "feature requests" before designing your "optimization methods". They customer guarantee, that there will never be a second doc in the company, but one month after you delivered the application ... They will never do scheduling for more than six months, but then laws changed and everybody must show an schedulded appointment for the next year, ... - imagine the worst case and it will came even worse.
* at the moment I prefer a good and practical OO-design over a database design. Traversing a tree of objects is much easier, than querying a sql-database. And there some of the suggested concepts come back in mind. E.g. create all months of the year, and all days of the needed month as objects, even if there's no appointment. If you e.g. need to search for the first friday 10:00 am free slot, start to querying for the friday appointments for the first month, next month, ... of course this sounds as hell in the ears of a "REAL"- sql-developer, but ask you self, how much time it will cost, I guess you will need significantly less than 52 queries. When consider an appointment cache, if possible, you'll going to need significantly less queries.
I think I stop here, because this is the RB-list, btw. of course all written above should be done with RB ;-)
ciao Thorsten Hohage -- that-Office.de Softwaredesign - Hamburg,Germany _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
