Hello. I apologize in advance if I'm spamming by creating a new thread, but it's so hard to get specific answers to custom database design, etc.
So here's my issue, and I was kinda looking for suggestions regarding where I can go from here. I just got access to this database that my department has, and from the get-go I have had a bad feeling about its size and design. It has a main table that keeps track of certain events. It also has tables that keep track of the players in the events. There's three main tables, "Event","Subject1", and "Subject2". Subject1 and Subject2 should really remain seperate.
Here's kinda my issue. For every Event the user has to input Subject1 and Subject2 into the Form (the Form is EVENT, with Subforms for SUBJECT1 & 2). Then the data gets dumped into their own stand alone tables and referenced back to the event with the Primary Key.
This database is 10 years old, and contains nearly 30000 records. So theres 30000 entries in EVENTS, 30000 in SUBJECT1, and 30000 in SUBJECT2. As you can imagine, doing QA on this is a nightmare.
So my question is this; Is there a way to make this better/more efficient? I'm sure from a design point there is (I have a couple ideas) but theres so much info already there, is it worth changing? I think it's a project that should be tackled at some point, this database is getting used for broader purposes all the time. Kinda leads to my next question, what would you suggest/recommend for redesigning/restructuring the database?
Thanks in advance to anyone that read my whole post and didn't fall asleep. I really appreciate it.
So here's my issue, and I was kinda looking for suggestions regarding where I can go from here. I just got access to this database that my department has, and from the get-go I have had a bad feeling about its size and design. It has a main table that keeps track of certain events. It also has tables that keep track of the players in the events. There's three main tables, "Event","Subject1", and "Subject2". Subject1 and Subject2 should really remain seperate.
Here's kinda my issue. For every Event the user has to input Subject1 and Subject2 into the Form (the Form is EVENT, with Subforms for SUBJECT1 & 2). Then the data gets dumped into their own stand alone tables and referenced back to the event with the Primary Key.
This database is 10 years old, and contains nearly 30000 records. So theres 30000 entries in EVENTS, 30000 in SUBJECT1, and 30000 in SUBJECT2. As you can imagine, doing QA on this is a nightmare.
So my question is this; Is there a way to make this better/more efficient? I'm sure from a design point there is (I have a couple ideas) but theres so much info already there, is it worth changing? I think it's a project that should be tackled at some point, this database is getting used for broader purposes all the time. Kinda leads to my next question, what would you suggest/recommend for redesigning/restructuring the database?
Thanks in advance to anyone that read my whole post and didn't fall asleep. I really appreciate it.