jayco437
Premium
join:2001-08-11
El Paso, TX
 ·AT&T Southwest
| reply to aSic
Re: MySQL How to structure database?
said by aSic  :So should I create a (seemingly infinite amount of) table for each unique class (date), with rows that contain the name/address/etc data? ...and just regularly drop the old tables (classes) as time passes? No. No. No.
Create a table, CLASSES. Create a table USERS. Use a "lookup" table, CLASSES_USERS to show which users are signed up for which class. This would allow for users to sign up for multiple classes using the same information.
Couple other ways to do it, but creating tables for each class is a no-no. |
|
aSic
Premium
join:2001-05-17
Wakulla, FL
clubs:
| Thanks jayco437 ! I knew there was something I was overlooking somewhere. I knew the thought of tables for each class seemed crazy, but my head is hurting, and I couldnt clearly think of any other way.
Now I've got some more googling to do on how to properly implement this. 
--
Teamwork is a lot of people doing what I say.
Who is Ron Paul? |
|
aSic
Premium
join:2001-05-17
Wakulla, FL
clubs:
| reply to jayco437
Just wanted to say thanks again. This spurred a new round of looking at different tutorials, and now I've got the basic layout for signups, and the instructors viewing thing actually working, although very ugly and insecure at this point. I knew there had to be a way to do it. Thanks for the nudge in the right direction.
--
Teamwork is a lot of people doing what I say.
Who is Ron Paul? |
|
jayco437
Premium
join:2001-08-11
El Paso, TX
·AT&T Southwest
| No problem. Its quite a common dilemma I think, until you get a firm grasp on creating relationships in databases. I remember asking myself the same questions years ago.
I actually started with one of the O'Reilly books on Access databases that included some basic info on database modeling.
I've actually looked at this book at B&N, and thought it might be a good beginner book (haven't actually read the whole thing myself though) »www.headfirstlabs.com/books/hfsql/
It's an O'Reilly book also. |
|
Ray
Mahnahmahna
Premium
join:2001-04-02
Mesa, AZ
| reply to jayco437
said by jayco437 :said by aSic :So should I create a (seemingly infinite amount of) table for each unique class (date), with rows that contain the name/address/etc data? ...and just regularly drop the old tables (classes) as time passes? No. No. No. Create a table, CLASSES. Create a table USERS. Use a "lookup" table, CLASSES_USERS to show which users are signed up for which class. This would allow for users to sign up for multiple classes using the same information. Couple other ways to do it, but creating tables for each class is a no-no. When your table names contain data, that's a code smell. 
--
ON DELETE CASCADE |
|
jayco437
Premium
join:2001-08-11
El Paso, TX | Interesting read. I'd never heard of the phrase before, but certainly understand what they're talking about. I like the taxonomy of the different "smells" there. All very common problems (or, solutions? that create more problems) |
|
Tenar
join:2008-01-02
Midland, ON
| said by jayco437 :Interesting read. I'd never heard of the phrase before, but certainly understand what they're talking about. I like the taxonomy of the different "smells" there. All very common problems (or, solutions? that create more problems) Yeah an interesting term, I've heard it used in a few blogs here and there. probably related to "information scent" from the SEO world. |
|
