I wonder what thoughts are on the following scenario. I am currently writing an app for a large organisation. The members may be assigned to a number of designated groups. "Vocational Groups" consisting of people who work in specific job classifications. "Branch Sections" consisting of people who work in particular areas. (E.g. Health, v Local Government ). "Committees" people who are on specific committees, and their various roles on these committees. Etc.
Currently each of these groupings had their own tables. Eg. "Vocational_Groups"
Members are assigned to a group
The same would take place for other groupings.
Currently there are seven of these type of tables, having various numbers of records. Each are very quick to read into grids, etc. Joins are simple and straight forward.
I am thinking of merging each of these tables into one long table. Lets call it "Group_Members". This would result in a table of some 7,500 records (note a member may belong to multiple groups) having the following structure.
ANd a corresponding lookup table.
As a consquence there would only be two tables as opposed to the fourteen ( one for each of the lookup group tables, and one for each of the related members).
Can anyone see anyone see any benefits in this longer 2 table concept? Joins?
As I said I was looking for views as to the best solution. Either way, I have imported all the other tables into one and am using individual queries to populate the picklists.
A bit like 'One ring to bind them!"