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
