-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank --
...and then Frank Peavy said... % % David, % Just some thoughts.. % See my comments below... Thanks! % % >A 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. % Sounds like you are on the right track. Looking at your first sentence % below, you state % that there are "various types of groups classes", so why not have a type of % 'private'. Yeah. In fact, I have that now, though it hasn't gotten me far. % % >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...) Right, and it certainly would be awkward. It seems to me that you have to have the instructor, the class type, the place, and the time before you can offer it to clients. So that was my worry. % % >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 Exactly; see above. % process has to control that i.e. you need to schedule class timeslots. OK. I like that. % 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? Right -- but that's not a good approach, IMHO. % % >% 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? % 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) OK. Yeah, I figured I'd have to do that on my own. I also want to make sure someone doesn't try to sign up a client in two spots at the same time, and will have to do that on my own. No biggie. % % Just to re-itereate, I think you want to enroll groups..! not clients..! % A client can be a group of one. Hmmm... OK; I can see that... % 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(?) John Smith, or maybe six or seven people taking a group class. % % 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. At the very least, it stores a lot of redundant data; you're probably right. Then I don't have to worry about how to define the time slots (are we open from 6a - 7p today or do we close at noon or whatever?) to ensure that the classes get booked only at appropriate times. So this part looks easy and helpful. Hmmm... I'll wait until later to figure out whether to stick with one field or split into day and time -- and then fret about all of those duplicated day values for each hour ;-) % % Your finally scheduling table would have pointers to places, timeslots, % personnel, groups, classes OK. Here's where I have more questions, then. The class type will say what kind it is and how many slots it can have, so I know what kind of 'group' can go in here. Are you suggesting that I should have a table defining a group for each instance? Basically every time you have an instructor doing something, you have a corresponding entry in another table listing who's being taught? That seems just a little *too* redundant, and maybe a little less so if I reused groups (every client would automatically become a group of one, to be reused for any private instruction, and then there would be other groups as people came together in a group class). Even so, that still doesn't answer the question of how to have data of different magnitude in the same table. If I have one class with one person and another with two people, how would I have a single record for each which lists the client(s)? Thanks again & HAND & HNY mysql query, :-D - -- David T-G * There is too much animal courage in (play) [EMAIL PROTECTED] * society and not sufficient moral courage. (work) [EMAIL PROTECTED] -- Mary Baker Eddy, "Science and Health" http://justpickone.org/davidtg/ Shpx gur Pbzzhavpngvbaf Qrprapl Npg! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+EzcbGb7uCXufRwARAidsAJ9/wP9r5V69KWmyyYT35XPOy2P3aACfYzxi +OROMSGH/Gdtbdb8NwEidY8= =AJER -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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
