2013-04-10, 07:15 AM
Hi All,
I am writing a sports tipping competition for my site and I am likely going to release this once I am happy with it.
Now one thing I have started to code and thought of two ways to handle this, and I thought it best to get your opinions.
Now there is a list of teams which will have data like
ID, team_name, team_logo, pa, pf, points, compID
now year after year I would be re-using the same teams, however everything is referenced off of compID. So I was writing an import feature that lets you essentially duplicate the team data then assign a new compID to it.
This is fine, however I started to wonder about people that may end up using this for some of the larger team sporting events, like football, etc. In those situations there is the potential that they may have 20 - 50 teams in the list.
So year on year they end up adding 50 records to the database for by and large the same information (besides points for, against and points)
This then gets compounded if they have multiple competitions on their site, like say a prize free comp and a paid come with prizes that are exactly the same, they then could end up with more records that are not really needed.
Now we aren't talking about massive amounts of records here, but I was wondering whether it may be better to break this up into a reference table
team_reference
which would have current_comp, ref_comp
It would then only add one record per duplicated competition and the rest of the code would then just go off check for a reference, if there is one use the other comp ID or if there is not then go direct to the team table.
Now the complication here is it may end up adding an additional query to do this, though again only minor, it is still an additional query at least once for a number of pages.
So what are your thoughts, should I just duplicate the data or go with the reference table.
I am leaning more towards duplicating the data because it adds more flexibility with standings and few queries, the data should never be massive, and even if it is an index on the compID should mean that it's never going to be a major issue.
Your thoughts?
I am writing a sports tipping competition for my site and I am likely going to release this once I am happy with it.
Now one thing I have started to code and thought of two ways to handle this, and I thought it best to get your opinions.
Now there is a list of teams which will have data like
ID, team_name, team_logo, pa, pf, points, compID
now year after year I would be re-using the same teams, however everything is referenced off of compID. So I was writing an import feature that lets you essentially duplicate the team data then assign a new compID to it.
This is fine, however I started to wonder about people that may end up using this for some of the larger team sporting events, like football, etc. In those situations there is the potential that they may have 20 - 50 teams in the list.
So year on year they end up adding 50 records to the database for by and large the same information (besides points for, against and points)
This then gets compounded if they have multiple competitions on their site, like say a prize free comp and a paid come with prizes that are exactly the same, they then could end up with more records that are not really needed.
Now we aren't talking about massive amounts of records here, but I was wondering whether it may be better to break this up into a reference table
team_reference
which would have current_comp, ref_comp
It would then only add one record per duplicated competition and the rest of the code would then just go off check for a reference, if there is one use the other comp ID or if there is not then go direct to the team table.
Now the complication here is it may end up adding an additional query to do this, though again only minor, it is still an additional query at least once for a number of pages.
So what are your thoughts, should I just duplicate the data or go with the reference table.
I am leaning more towards duplicating the data because it adds more flexibility with standings and few queries, the data should never be massive, and even if it is an index on the compID should mean that it's never going to be a major issue.
Your thoughts?