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 (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