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.


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.
>PHP Database Mailing List (
>To unsubscribe, visit:

PHP Database Mailing List (
To unsubscribe, visit:

Reply via email to