By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,509 Members | 2,201 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,509 IT Pros & Developers. It's quick & easy.

storing data in a table

robin a
P: 30
I am using access 2007. This is a training database in which classes are assigned to employees by their job title. I have the Class_Catalog table which stores all class information, including a job_title field. My problem is, now that I am importing data, I've found that since up to everyone in the company (450 people) are required to take many of these classes. I don't want to add the same class 450 times with each applicable job title because I don't think that's the smart way to do it and I don't want to bloat the database. I can't think of any other way to make sure classes get assigned to the proper job_titles.

I would appreciate any suggestions.
Sep 19 '12 #1

✓ answered by Seth Schrock

That is correct. The problem with the multivalued field is that if you would ever want to query the database to see what classes a certain job title, it would require a lot of coding. Even if you don't need that ability now, it is always best to design a database according to normalization rules. This allows you to add to your database without having to make major design changes to the existing database. Also, because the join table is just those two fields (occasionally there are more, but in this case there are only two) you don't have to worry about bloating the database. To save you from having to type everything, you can create a form based on the join table and use combo boxes to populate the table.

I believe I might have forgotten to mention adding the relationships between the three tables. Classes table related to the join table as one-to-many and job titles table related to the join table the same way.

Here is something else you can do to make it easier to add all of those combinations. Say you have a form for your classes based on the classes table and a form for your job titles based on the job titles table. We will name them frmClasses and frmJobTitles respectively. You would then create a form in datasheet view based on the join table. We will call it frmJoin. You would then put frmJoin on frmClasses as a subform. You can also do this on frmJobTitles. Because of the relationships, access will be able to automatically find the relationship between the main form and the subform form. This will make it so that you only have to add information to the one field instead of both.

Share this Question
Share on Google+
8 Replies


robin a
P: 30
I wanted to add that there are only 38 job titles. would making job titles a mutli-valued field work or would it complicate all of my queries?
Sep 19 '12 #2

Seth Schrock
Expert 2.5K+
P: 2,931
From what I'm reading, I believe that you would want a table of job titles and a table of classes. Also, since each class could be assigned to multiple job titles and I'm assuming that each job title could be required to take multiple classes, you have a many to many relationship which requires a joining table. This would consist of the primary keys of the two tables. You then set the combination of those two fields as the primary key of the joining table. This would allow you to make all the assignments needed.
Sep 19 '12 #3

zmbd
Expert Mod 5K+
P: 5,287
Seth is certainly on the right track here with normalizing the database. I've sent you a PM with several links that might prove helpfull
Sep 19 '12 #4

Seth Schrock
Expert 2.5K+
P: 2,931
I wouldn't do a multi-valued field as it would really complicate your queries.
Sep 19 '12 #5

robin a
P: 30
Seth,
Are you saying that after creating the join table, I would still add a lot of records to the class_catalog table? e.g. with a multivalued field it would look like this:

Class_ID Job_Title Class_Name
1 machine operator, handpacker, coach first aid

if it isn't multivalued it would look like this:

Class_ID Job_Title Class_Name
1 machine operator first aid
2 handpacker first aid
3 coach first aid
Sep 19 '12 #6

Seth Schrock
Expert 2.5K+
P: 2,931
That is correct. The problem with the multivalued field is that if you would ever want to query the database to see what classes a certain job title, it would require a lot of coding. Even if you don't need that ability now, it is always best to design a database according to normalization rules. This allows you to add to your database without having to make major design changes to the existing database. Also, because the join table is just those two fields (occasionally there are more, but in this case there are only two) you don't have to worry about bloating the database. To save you from having to type everything, you can create a form based on the join table and use combo boxes to populate the table.

I believe I might have forgotten to mention adding the relationships between the three tables. Classes table related to the join table as one-to-many and job titles table related to the join table the same way.

Here is something else you can do to make it easier to add all of those combinations. Say you have a form for your classes based on the classes table and a form for your job titles based on the job titles table. We will name them frmClasses and frmJobTitles respectively. You would then create a form in datasheet view based on the join table. We will call it frmJoin. You would then put frmJoin on frmClasses as a subform. You can also do this on frmJobTitles. Because of the relationships, access will be able to automatically find the relationship between the main form and the subform form. This will make it so that you only have to add information to the one field instead of both.
Sep 19 '12 #7

TheSmileyCoder
Expert Mod 100+
P: 2,321
What Seth and zmbd are saying is the "best practice" approach to the problem. People tend to think that the multivalued fields are nice to use, but if you look around a bit on the net, you will see that almost all seasoned access developers will tell you not to use that feature.
Sep 19 '12 #8

robin a
P: 30
Thank you everyone. I now know NOT to use the multivalue data type. Turns out my existing design included a join table and it works well. I just don't like having to put in a class up to 40 times BUT, I do have a selection for ALL that assigns to every employee. Everyone's advice was very clear and helpful. Thank you everyone.
Sep 20 '12 #9

Post your reply

Sign in to post your reply or Sign up for a free account.