Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm currently trying to build a football database in MySQL. It should store the fixtures from different leagues, plus their results, odds and some other information.
Is the scheme I just created correct or are there any mistakes in it? If so, what can I improve? I'm also not really sure about the link between tblMatch and tblTeams.
Afterwards I want to be able to make a Query where I can select a fixture including the points the home and away team got before the match, plus the average amount of goals of the teams. Like the new fields: 'homeTeamPoints', 'awayTeamPoints' ect.
So my question is: Where should I put these fields? In an extra table or should I put those in the table: 'tblMatch' and store the precalculated values there?
I hope you get what I tried to explain.
Best Regards
-bababow
A few notes:
You will want to replace "homeTeam" and "awayTeam" with "homeTeamID" and "awayTeamId" which will be foreign keys to the tblTeams table. This will enforce that the teams in the match both actually exist.
Remove the matchID and competitionID from the teams. I'm assuming teams can participate in many matches and competitions and therefore this structure will not support that.
What do you want to know about competitions? Is this a tournament? You may want to have a "bracket" and/or "tournament winner" column in there to store the results of the overall tournament.
Those are my main thoughts, other than that it looks OK.
In my perspective if the values of both the fields needs update regularly and table tblMatch data size is large then you should take it into separate table. if both the fields are updates whenever whole record is change then it could be in tblMatch table.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I must to make a decision if I split my table in more tables or I keep all in one table. According to my calculation if I will keep all in one table my table will have estimated 300.000 rows per year. Some people say to me to split table for every year. example 2019_table..
Some people say to split table in 4 tables(subcategories). I need an advice how to do it.
This is my current table https://ibb.co/jfZMKQJ
300K records is not really a large amount, and even over a decade, it is only 3 million records, which also is not very large. Assuming you can tune your database with appropriate indices, I don't see any reason to split into multiple tables. Even if you did have the need for this, you could try something like partitioning the table first (see the documentation).
300K records is not a large amount. Instead of splitting the tables, you better have to put an index on your datetime field assuming it is one of the fields you will use to filter your data.
See this answer for more details: Is it a good idea to index datetime field in mysql?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm trying to find the best solution for my needs. I have a budgeting application that each user will have their own budget which will include potentially hundreds or thousands of budget entries. Initially I thought I would have a table for the users and basic info, and then each user would have their own sql table with all of their budget items held within. However, if the user list grows to hundreds or thousands then I would have a large amount of tables since each user would have their own. I also considered a single table to hold everyone's budget entries but I'm not sure that's the correct solution either.
Any advice? Thank you in advance
I think a single table that holds all the budget entries, with a primary key that's referenced by a foreign key in the "users" table, is a good way to go. You can always use something like select * from users u join budgets b on u.userID = b.userID where userID = xxx to get the budget items for a particular user.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have two tables in my db:
Marketers:
Id, Username, Password, Email
Stores:
Marketer Id, 1 Store, 2 Store, 3 Store, 4 Store, ...., 10 store
there is the names of 10 stores for every marketer in Stores table.
So there is a one to one relationship between these two tables. right?
I'm wondering if it would be better to just combine these two tables or not.
I wan't to send a lot of query for the second table (Stores tables). so I though this would be better if I separate these two cause I rarely need the information stored in 'Marketers table'.
From a good design perspective, you should keep these tables as separate.
for your current requirements,
if you do not need data from Marketers so often, why do you need to include that in Stores. you would just end up fetching extra data each time.
say if tomorrow if some new info and the mapping changes to one to many or vice versa, your current design will work perfectly fine.
and of course from future maintainence view, it is easier to update current design.
although, i would also, suggest you to add an independent primary to Stores table also.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have two tables that should somehow be associated. Let's call them table_a and
table_b. A row in table_a can be associated with multiple rows in table_b, and the same goes the other way around. How could I achieve this? Should I use a pivot table?
Both tables have an auto-incrementing id-column.
What you're looking for is called a many-to-many relationship (a given user has zero or more games, a given game has zero or more users). This is typically handled with a "mapping table", e.g. USER_GAMES which has a user_id and a game_id, uniqueness is on the combination of these. http://www.joinfu.com/2005/12/managing-many-to-many-relationships-in-mysql-part-1/ has some good details.
As it is a many to many relationship, an intersection table with the user ID & game ID would be the best. Otherwise you would have to parse the list of game ID's stored in the user table and that would cause performance issues.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a table that will hold 'game stats'. The name of the stats that are held are going to be changing depending on which sport the stats are for.
Is best practice to make two tables: one for the stats with columns such as 'Stat1, Stat2' etc. and another one holding the titles with the sportID as a key. Or would the best practise to have several tables for resorts for each sport. Or any other way?
Thanks,
I agree with andy. A generic-titled column like Stat1 - where the purpose is unspecified in the column name, is used polymorphically, or the column type must be made more generic - usually indicates a poor SQL/RA design.
Consider if this were encountered: create table people (field1 varchar(20), field2 varchar(20)). Yeah - not going to fly in my database. Give the columns (and tables) names that mean something in relation to purpose.
Instead, each different type of information collected should have it's own entity (read: table) or group of related entities. In this case I would imagine that each sport represents a different type of collected stats/information. (Even Win/Loss information can vary by sport.)
Trying to "label" columns based on an additional table is a half-way attempt of an Entity-Attribute-Value (EAV) model. While an EAV can be useful it comes with a lot of downsides in SQL and should not be used except after very careful consideration for a specific use-case. (I do not believe that EAV fits this scenario appropriately.)