-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank, et al --
...and then Frank Peavy said... % % David, % I am unsure if I followed your example completely, but maybe this might % help. Not knowing your complete database structure, I am unsure if my % comments will be entirely valid but here goes. I didn't want to throw the whole thing to the list; I thought that might be considered rude :-) % % I think you could achieve your goal if you think of your groups as Hmmm... You mean like a group class? % containing one or many clients. Each single client would be in a group of % their own. Yes, this is a little strange, but it makes the structure a lot Not necessarily; I already think of a private instruction as basically the same as a group instruction except only one slot. I don't know that I've managed to *write* the schema that way, but that's how it's in my head ;-) % easier and consistent. So this is what you would have: % % Time slot --< class --< group --< client % % So the structure, in english: % Each time slot has a one-to-many relationship to classes % Each class has a one-to-many relationship to groups % Each group has a one-to-many relationship to clients Here's where I'm not sure how to make that fit -- probably just because of my own terminology. 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. I currently have a clients table, a classtypes table (various types of group classes), a personnel table (instructors), a places table (what room), and a schedule table (drawing from each of these plus a timeslot field). When I have a private classs I just leave the classtype empty (but I'm open to change). 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; I don't get it), the instructor, and the time slot 'cuz the location (maybe), the type, and the clients in it are set in the class table. 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? % % 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? % % Hope this helps........ It's a start; thanks a bunch! HAND & HNY :-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+EykaGb7uCXufRwARAi6CAJ9ACpgYWfWhHSaaLRBitc5bHL7tZgCfceL9 KTGOGwF4KfWPUNVSrLcYlEw= =+giV -----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
