David, Just some thoughts.. See my comments below...
Sounds like you are on the right track. Looking at your first sentence below, you stateA scheduling, or a booking, eventually has to have a class type (private or one of many groups -- so I suppose I could simply make a group class type 'private' and that type has only one slot), an instructor, a place, a time slot, and the client or clients to go in it.
that there are "various types of groups classes", so why not have a type of 'private'.
If I get you right, I'd have a class table pulling together the type of class (one of the typical group classes or this new 'private' one) and, somehow, the client(s) enrolled, and then the schedule table need only have the class instantiation (which doesn't yet make sense without a timestamp;
This is unclear, what do you mean by timestamp...do you mean it has no time scheduled? From a technical standpoint, this is not an issue, but from a business standpoint, you would have people enrolled in a class that has not been scheduled. (Can happen but awkward...)
First, I wonder if I successfully followed you :-) Second, though, I don't get how I can have some clients in a class table when the class hasn't been assigned a time slot; how can the clients avoid collisions?
This is unclear "collisions"?... Are you asking how the clients would avoid double booking themselves? If that is the question, I think your business process has to control that i.e. you need to schedule class timeslots. Or, as the classes get scheduled, you would have to notify your clients about the schedule. Wouldn't you have to do that any way, since they would not know when the classes are supposed to be? I
You run a query that counts the number of classes that are booked for each location at each timeslot and if the count is greater than 1, you have a problem. (simple SQL query would give you this)% Now, you can query the database and see how many time slots have more than % one class. % You no longer need to worry about double booking..... Because I can come back to an unique index, you mean, perhaps?
Just to re-itereate, I think you want to enroll groups..! not clients..!
A client can be a group of one.
This allows you to enroll "groups" of one or many.
I am assuming that your clients may be, for examplle, John Smith or local community center(?)
Also, if it was me, I would probably create a table for time slots. The way you have it structured, it works but it is not as flexible.
Your finally scheduling table would have pointers to places, timeslots, personnel, groups, classes
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
