I am working on database for scoring system for my friend. I have table with games and second table with names of sports (footbal, tenis, floorball). I want to store scores of the games but I don't know how to design database for specific needs of scores.
For example:
Football score - 1:2, 2:2 (1st and 2nd half)
Tenis sets - 6:4, 7:6
Floorbal - 1:0, 3:0, 3:2 (1st, 2nd and 3rd part of the game)
I need this score linked to games table, but I need specific table columns for storing score for every game.
I think about:
Multiple tables and and foreign key, but this is not possible in mysql.
Then I think about storing data in json in one row and then parse it specifically based on sport, but probably this is not very good solution.
The only problem from my point of view is:
How create table/s for storing scores in different format based on type of sport?
Thank you for any help
E.g.:
match_id | period_id | team1_score | team2_sore
1 | 1 | 1 | 2
1 | 2 | 2 | 2
2 | 1 | 6 | 4
2 | 2 | 7 | 6
3 | 1 | 1 | 0
3 | 2 | 3 | 0
3 | 3 | 3 | 2
You mention MySQL, so it appears that you want to develop a relational database.
The first step is to define the relations. Based on your example.
A game has one sport.
A sport has zero or more games.
A game has one or more period scores.
A period score has one game.
Based on these relationships, we can define 3 tables.
Sport
-----
Sport ID
Sport name
...
Game
----
Game ID
Sport ID
Game name
PeriodScore
-----------
PeriodScore ID
Game ID
Period
Score
The primary ID fields are known as blind keys. They are auto-incrementing integers. Their sole purpose is to tie the game with the sport, and the period scores with the game. Otherwise, they have no meaning at all. The primary ID fields are the primary (clustering) keys of their respective tables.
The Sport ID in the Game table is a foreign key. This key points back to the Sport table, so you can get the name of the sport. You can create a unique index on (Sport ID, Game ID) if you ever want a list of the games for a particular sport.
The Game ID in the PeriodScore table is another foreign key. You must create a unique index on (Game ID, PeriodScore ID) so that you can retrieve the period scores in the correct order.
When you want to create a relational database, you first define the relationships, then go through a process of normalization.
Related
the first is the sectors table that has an id and sector name like this
id | sector
1 | Government
2 | Education
The second is the employee table like this (simplified)
Id | name
1 | sam
2 | tom
Finally I have a sectorMap table (this is used to join the two tables above together) like this
Id | sectorid | employeeid
1 | 1 | 2
2 | 1 | 1
3 | 2 | 2
So in this instance, once I join everything together and view the sectors or each employee, it would show that tom has two sectors (government, education) and sam only has one (government)… hope that makes sense
My question is, within my application, the user has the ability to change these sectors by selecting from a multiple selection dropdown in html. For some reason I thought that by doing an update on duplicate expression would work, however seeing how I have multiple rows of data, I would need to delete all rows within the sectormap table that do not reflect the new selection and contain the selected employees id. What would be the best way of going about that?
For instance, in this case, lets say I open the application and see that tom has two sectors tied to him (government, education) and I only wanted him to have one (government). When I deselect education and select GO. The application returns a list to the server that contains (‘government’). How can I formulate an expression to delete the education sector row from the sectormap table that contains his id?
Your answer is in your question.
1st when you are deselecting education. You will get data of (‘government’). right?
So just invert your query. select those records which is not (‘government’), those are education.
So, education records are you can delete.
Hope this will help you. thanks:)
I have two table now:
conference table: id, name
people table: people_id, name
what I want to do
I want to make a new table so that I can get all attend people by conference id but also get all conference a specific man attended by people_id.
what I have thought
make a new table whose columns is all the people's id, and insert each conference as row, if the people shows in conference, we make it 1, otherwise 0. But it's too sparse and difficult to show which people attend a specific conference because we have many columns.
UPDATE
thanks for your comment. Now I create a table like this:
I think it's much better than the table before.
How about this?
A join table called conferences_people.
cp_id | conference_id | people_id
-------+---------------+-----------
1 | 1234 | 1
2 | 1234 | 4
3 | 1234 | 5
I am trying to create a database schema regarding betting being played with numerous betting providers. Some betting providers have 15/13/16 etc games per pool.
E.g. Provider A (ID 1) has Liverpool Vs Man City has 1 of its 15 games and Provider B (ID 2) also has this match for one of their 13 games.
Can I record this like the following;
Match ID 1
Provider ID 1,2
Home Team Liverpool
Away Team Man.City
Bookmaker Pinnacle
Is that possible or can SQL not store to id's for 1 primary id?
I am trying to keep a record of each match for each pool so I can then record what the betting prices were by specific bookmakers and what the payout percentages were for future references.
Is there anyway this can be done?
E.g. Provider A (ID 1) has Liverpool Vs Man City has 1 of its 15 games and Provider B (ID 2) also has this match for one of their 13 games.
Can I record this like the following;
Match ID 1
Provider ID 1,2
Home Team Liverpool
Away Team ManCity
Bookmaker Pinnacle
Is that possible or can SQL not store to id's for 1 primary id?
Not coded yet, currently working on creating the database schema
This is a common misunderstanding with foreign keys. If you think you need to store two IDs in one record's foreign key, your foreign key is in the wrong place.
In your case, if a match can have many bettors, and a bettor can have many matches, you need a many-to-many or "junction" table, linking matches to bettors.
Your schema might look something like this:
table matches:
id | Home Team | Away Team
----+-----------+-----------
1 | Liverpool | Man.City
table providers:
id | name
----+------------
1 | Provider A
2 | Provider B
table provider_matches:
provider_id | match_id
------------+----------
1 | 1
2 | 1
Your table provider_matches now has two foreign keys, which can be enforced through foreign key constraints, linking both providers to the same match.
Making CMS to manage restaurants. Briefly, there are restaurants that have their own divisions. Also, there are meals that need to be assigned to a restaurant (so all its divisions can see those meals) or individual division(s) (so only selected division(s) can see meals).
So I created tables:
restaurant_id | restaurant_name
1 | Restaurant 1
2 | Restaurant 2
division_id | restaurant_id | division_name
1 | 1 | 1-1
2 | 1 | 1-2
3 | 2 | 2-1
4 | 2 | 2-2
meal_id | meal_name
1 | Steak
Also created mapping table meals_to_restaurants_divisions that contains 3 columns - meal_id, restaurant_id, division_id
So, if I want to assign meal to Restaurant 1 and ALL its divisions, I would create record:
meal_id | restaurant_id | division_id
1 | 1 | null
If I want to assign meal only to division 2-2, I would create a record:
meal_id | restaurant_id | division_id
1 | null | 4
Could someone advise if such a scheme is correct? How could it be improved? I know someone will say I should only create mapping table with 2 records - meal_id and division_id and assign meal to all divisions instead of assigning to a restaurant, but here's the catch: if Restaurant 1 gets new division created in future, I want new division to inherit the same permissions (so if existing meal is assigned to a restaurant instead of division, all future divisions will inherit restaurant's permissions). Otherwise, I would need to manually edit every meal and assign a new division to it.
If someone is interested why I use null in restaurant_id in 2nd example, it's because if division's parent is changed later (division is assigned to another restaurant), I don't need to scan mapping table and change restaurant_id value there.
To evaluate if your model is correct, the most important aspect is that it fulfills all requirements. Since your description is not complete, we cannot verify that for you. You may e.g. check if devisions can belong to several restaurants at the same time. Or if you have other attributes for devisions (e.g. staff assigned to a devision, the order history, outstanding royalties or ratings on your website), that change or do not change when you move a devision to another restaurant. You could also think of that process as creating a new devision inside another restaurant and assigning all meals to the new devision (or maybe several devisions). It is more a conceptional question than a formal one, and if it is correct (and also if there is a better one) will depend on the requirements.
Formally, your model is correct, as long as you never set both restaurant_id and division_id in your "permission" table, because such an entry would not make any sense. (And as long as restaurant_id is not part of the key in your devision table, which is not the case according to your description).
Your table is basically a flattened 2-level-tree with some implicit conditions. A more general tree could look like
id | parent
---+-------
1 | null -- restaurant "1" (has no parent)
2 | 1 -- devision "1-1"
3 | 1 -- devision "1-2"
4 | null -- restaurant "2"
5 | 4 -- devision "2-1"
6 | 4 -- devision "2-2"
In this tree, a restaurant would be treated like a normal devision (or a devision would be like a sub-restaurant), and you could assign meals to just that id. If you want to assign meal 1 to restaurant 1 and all its divisions, you would create the record meal=1, id=1. If you want to assign meal 1 only to division "2-2", you would create a record meal=1, id=6.
It implicitly prevents you from a situation where you would assign both restaurant_id and division_id to a meal (which is the mentioned condition in your model), as such a combination does not exist anymore. You "flattened" the tree by moving the parents into the restaurant_id and the (1st-level-)children to the devision_id-column of your meals_to_restaurants_divisions-table.
The tree will not enforce that a restaurant cannot belong to another restaurant or that you cannot have sub-sub-devisions. Basically, you treat restaurants explicitly NOT as a special kind of devision (or vice versa).
So both models, while formally correct, have a lot a implicit conditions that they automatically enforce (like the maximum depth in your model), that you would have to enforce manually (like not setting both columns in your model, or the maximum depth in the tree) or that are not supported (like subdivisions in your model). You will have to compare that to your requirements.
A site note: a tree is actually a bad model for hierarchical data in a database, as it gets complicated to (recursively) query several levels deep, and there are better models. I just used it for simplicity - and since you only have 1st-level-children, this restriction does not apply in your case.
Not worded my question very well, but with these tables:
USER TABLE ANIMALS
u_id username a_id animal
-------------------------- ---------------------------
2 alice 1 cat
4 brian 2 small dog
7 carla 3 big dog
4 rabbit
5 guinea pig
etc.
I want a user to be able to add however many animals they own to their profile.
What new tables/fields and datatypes would be the best way for me to go about this?
Thank you.
If you need to allow multiple types of the same animal per user (Janet can have more than one Rabbit) then do the following. Make UserId and AnimalID your primary key.
I would just do
UserAnimals
------------
UserId
AnimalID
Filled with data your table might look like this:
UserAnimals
------------
UserId || AnimalId
4 || 3
4 || 2
7 || 4
Brian has a small dog and a big dog. Carla has a rabbit.
Essentially you need a table which will map user ids to animal ids.
If you want to add them 1 at a time, you could just use a table like so:
UserAnimals
-----------
UserID (fk to User Table)
AnimalId (fk to Animal Table)
Assuming they might own, say 3 dogs, and you want to track the number, you could either have a row per animal or you could modify the table to include a count of the animals of each type:
UserAnimals
-----------
UserID
AnimalID
Count
I'd probably do it that way if I knew that there was a good chance that folks would have multiples of a given animal, otherwise there's a little more work to do whenever retrieval takes place to arrive at a total.
I guess one could make the argument that the ID field isn't absolutely necessary for the animals either. It could just be a lookup table of strings, though that requires a bit more space for storage and complicates things a little bit if you decide that you want to modify animal names for some reason.
I would recommend you many to many relationship table.
Example:
table: users_x_animals
-----------------------
pid | u_id | a_id
1 2 3
2 4 5
3 2 5
4 7 1
5 4 2
This way if you have index (separate) on u_id and a_id you can either query for "animal with id X is owned by users" or the other way around "user with id x owns these animals".
Hope that helps. :)