Don't want to get too philosophical, but don't PIM/Contact Management
projects like TWIG have a feature like this?
Now, this is just off the top of my head, but rather than create a
timeslots table, wouldn't you have an event table, and a member_booked
table? The minimum fields in event would be event_id(primary), start_time,
end_time. Member_booked fields could be member_id, event_id, with maybe
start_time and end_time, these two representing when the member is booked
for an event.
If a member is not found for a given event/time range in member_booked,
presumably she's available.
Note that event is generic, and could apply to any resource: meeting room
equipment, meeting, etc.
Downside to this, is that every member's scheduled event has to go into the
member_event table, but it seems small so retrieval and update should be fast.
Remember, this is a first kick at the can, and I'd bet there's a better way
of doing it.
Miles
At 09:22 AM 8/21/2002 -0500, Matthew Crouch wrote:
this is a big question and i'm not trying to get you to do my modelling
for me, but if anyone has experience with this i'd appreciate being
pointed in the right direction:
How could one efficiently manage time slots in a dB? I mean for example
telling the dB that Mike can be somewhere at 6:15 or 6:30 but not 6:45,
and that Cynthia can be there at 6:15 or 7:00...
...and so on
my instinct is to create a timeslots table, but it looks like it would
contain 35,040 records (one for each 15-minute period in the year). egad!
The alternative is to create timeslots a month at a time or something, but
the table would have to be reformulated every month.
any thoughts? feel free to get philosophical about it.
-M
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
