Thank you all for your insigth of this "common" Aganda problem.
Thorsten, your solution with tree like structure is certainly very good
but as I come from a database background I really would like to stick
with a Database to handle the business.
Adam : Very interesting this world of GA. I found a lot of literature
about it on the net and I will gzt into it for some later project.
I think that the most apropriate solution for my problem and knowledge
will certainly be the "brute force" one with the enrichment of Norman
idea about the pool of slots. This seems to work also for Fred (merci au
passage).
Best regards,
Youri
Thorsten Hohage wrote:
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>
_______________________________________________
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>
