I would like to develop a system, where user will get the data dynamically(what I mean dynamic is, without reloading pages, using AJAX.. but well, it does not matter much).
My situation is like this. I have this table, I called it "player", in this player table, I will store the player information like, player name, level, experience etc.
Each player can have different clothes, start from tops(shirts), bottoms, shoes, and hairstyle, and each player can have more than 1 tops, bottoms, shoes etc.
What I am hesitated or not very sure about is, how do you normally store the data? My current design is like this:
Player Table
===========================================================================================
id | name | (others player's info) | wearing | tops | bottoms
===========================================================================================
1 | player1 | | top=1;bottom=2;shoes=5;hair=8 | 1,2,3| 7,2,3
Tops Table
=====================
id | name | etc...
=====================
1 | t-shirt | ...
I am not sure if this design is good. If you are the database designer, how would you design the database? Or how you will store them?
Please advise.
Thanks
In short: instead of putting the column "wearing" in, you should make a table that connects the 2 tables (players and clothes.)
You'd get
players
id name
1 player1
clotheTypes
1 top
2 bottom
clothes
id name type
1 shirt1 1
2 shirt2 1
3 pants1 2
wearing
playerId ClotheId
1 1
1 2
But please, do read the article taht #badcat shared!
edit: as requested, some hints:
You don't want this generally:
id name computer
1 john work, laptop, desktop, oldcomputer
Because you that should be in a seperate table. Now you can actually add, later on, the brand and speed of the computers: you can't the way you're doing it right now.
Person
id name
1 john
computer
id name owner
1 work 1
2 laptop 1
3 desktop 1
....
Seems like you are new to this.
Please read this article on Wikipedia about database normalization:
http://en.wikipedia.org/wiki/Database_normalization
Personally I would not do it like in the example above, because you'd have to update the players' table every time some T-Shirt is added or removed.
You need to create an additional tables for clothes, something like this:
player
id_player //1
name //Jhon
level //6
experience //13
player_cloth
id_player //1
id_clothe //5
cloth_types
id_cloth // 5
type // hat
description // very warm
Once you have created the tables you need to relate this data, you only need the id_player value.
Related
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
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I have a question about database that I'm currently trying to design, I also would like to mention that I am a beginner so please keep that in mind.
So, the DB that I'm currently designing will be used for my application that I'm developing for school project. The application will be a fitness app which will have number of features but the main focus will be on creating diets based on some information provided by the user. All the data to generate such diet will be taken from the DB such as food and its nutrients etc.
The way I want to construct this diet is so that it will create be a sample diet for a period of 7 days. On each day there will be 5 meals, and each meal will contain number of products e.g 100g chicken breast, 100g brown rice, 100g broccoli.
I've made a ERD diagram to help me model this which you can see at the following link
http://imgur.com/0ivcM5x
As you can see from the picture I've created Food table which will hold all sort of food items that can be used to create the meals, and This is where I get stuck. In my model I have broken it down into separate tables but I don'k know whether that is correct and will work.
I'm also not sure how to create that "MealTable" so far I've got meal_id as PK and food_id as a FK but will I be able to to create Meals with multiple food items or will it be 1 meal 1 item from "food" table.
Similar with the "DietTable" and "dayOfTheWeek" I am trying to take similar approach here so I've got diet_id as PK and day_id as FK but will that allow me to have multiple "day" instances within the same diet.
I know this questions are not really specific, but I'm just trying to understand how to model this and whether this approach is correct. Will it work and are there any other alternative ways to model similar problems.
Any help or suggestions would be appreciated.
I think your ERD diagram looks pretty good, but I noticed a couple things:
It looks like your MealTable table will be having more than one row per meal, so I would rename it to MealFood to list all the food items in each meal. If you need to add fields to each meal (such as the name of the meal), then make a separate table called Meal that will have just one row per meal
I would remove day_id from DietTable and instead have a diet_id column in the dayOfTheWeek table. If you pair this with a mealOfTheDay column, you could make a unique key across diet_id, day_id, mealOfTheDay to make sure each diet only has one meal for each meal of the day
Example dayOfTheWeek table:
| diet_id | day_id | mealOfTheDay | meal_id |
---------------------------------------------
| 1 | 1 | 1 | 999 |
| 1 | 1 | 2 | 642 |
| 1 | 1 | 3 | 242 |
| 1 | 1 | 4 | 298 |
| 1 | 1 | 5 | 322 |
| 1 | 1 | 5 | 111 | <- Unique key will not allow
this row as it's the second
fifth meal on same day for
diet 1
Also, try to keep you naming consistent. Some of you table names end with Table and some don't.
I've been looking to your database model, and there's some things that are missing and other that needs to be change (my opinion). I've already disigned a similar model, not for fitness, but I need to follow meals protein for a PKU disease. Your final model is (I think) really near than what I've designed :
Here are the list of tables :
FOOD : As you've done, except that in my case I'm using it to describe the proteins for 100g of this food.
FOOD_UNIT : mass units (mg, g, ..., Kg), volume (ml, cl, ..., L)
FOOD_CATEGORY : Vegetables, fruits, ...
CALENDAR : Date, day by day... I think it would be more usable for you than using a simple day of week ID and a meal ID. If soneine start the diet on monday and another one on Friday, they will eat exactly the same meal but in fact maybe the first person needs more or less food than the other one. Actually you have a big problem on this.
MEAL_PERIOD : Morning, ... Evening. Use time here helps to precise if meal was taken in early morning or nearby from lunch
PERSON : For who you are editing the meal. Several persons with differents needs in proteins, fat, ...
MEAL : I think you know what to put here (primary key on person_id, calendar_id, meal_period_id). Add all food and quantity in this table. Don't forget to add the foreign key on food_unit_id, and in your case your diet_id
Can't draw a schema now, but normally you have all the elements to draw a cool diagram that will normally fit your needs.
Lets say I'm storing play by play info for sports: basketball, football, and baseball. The data basically fits the same model:
| play_id | play_type_id | play_description_id | player1_id | player2_id | player3_id |
Those are the basic columns that each sport would share, but there would be several more. Some columns would only be used by certain sports - like player3_id would be used by football for who made a tackle, but never by basketball - there wouldn't be a lot of these limited-use columns, but some.
Each game can have anywhere from 300 - 1000 rows (high estimate), so this table could grow to the billions eventually.
My questions are:
Should I just start off with different tables for each sport, even though there'd be about a 90% overlap of columns?
At what point should I look into partitioning the table? How would I do this? I'm thinking of archiving all the plays from the 2012 season (whether it be a sports specific table or all-inclusive).
Sorry if my post isn't more concise. This is all a hypothetical case, I'm just trying to figure out what the disadvantages of having one massive table would be, obviously performance is a consideration, but at what point does the table's size warrant being divided. Because this isn't a real project, it's hard to determine what the advantages of having a table like this would be. So again, sorry if this is a stupid question.
EDIT/ADDITIONAL QUESTION:
On a somewhat side-note, I haven't use noSQL DBs before, but is that something I should consider for a project like this? Lets say that there'd be a high velocity of reads and return time would be crucial, but it also needs to have the ability to run complex queries like "how many ground balls has playerA hit to secondbase, off playerB, in night games, during 2002 - 2013?"
I would separate it in multiple table. That way it is more flexible.
And if you want to make some statistics your are gonna be able to do more complex queries than if you have only one table.
It could look like this
Table PLAYER
ID | FIRSTNAME | LASTNAME | DATE_OF_BIRTH
-----------------------------------------
1 | michael | Jordan | 12.5.65
Table SPORT
ID | NAME | DESCRIPTION
------------------------------------------
1 | Basketball | Best sport in the world
2 | Golf | Nice sport too
Table PLAYER_SPORT
SPORT_ID | PLAYER_ID | PLAYER_POSITION_ID
--------------------------------------------
1 | 1 | 1 /* Michael Jordan play Basketball */
2 | 1 | NULL /* Michael Jordan play also Golf */
Table PLAYER_POSITION
ID | POSITION | DESCRIPTION | SPORT_ID
-------------------------------------------
1 | Middlefield | Any description.. | 1
As far as your table structure is concerned the best practice is to have another table for Mapping play_id and player_id. There is no need of columns player1_id,player2_id,player3_id. Just make a new table which has play_id and player_id columns.
Should I just start off with different tables for each sport, even
though there'd be about a 90% overlap of columns?
I don't think that would help you much, the problem of growth rate for a single table will occur for segmentation-ed tables, this kind of distribution will just make a delay and will not solve the problem. Also you will lose integrity and consistency by violating Normal Forms.
At what point should I look into partitioning the table? How would I
do this? I'm thinking of archiving all the plays from the 2012 season
(whether it be a sports specific table or all-inclusive).
You need to use logical database partitioning.
I think a range partition on mach-date field will be helpful.
Documents about MySql partitioning could be found here.
Recomanding to use NoSql will need more information about your application, BTW NoSql will come with its pros and cons. Having a look at the post may helps.
.
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. :)
Still working on a web application as a school project, and it just seems to keep expanding.
I have to add a layer for teachers so they can manage and coach students through the application. So, I have to link teachers to their students.
I was wondering what the best way would be to do this. I have one table for all users at the moment. The bare basics of this table are:
id | email | firstname | lastname | role
1 | s#s.s | dromiceio | mimus | 1
2 | d#d.d | tyranno | saurus | 2
3 | a#a.a | utah | raptor | 1
Role is the number I assign to them to give them certain permissions. 1 = student, 2 = teacher, 3 = admin.
Assuming that one student has one teacher but one teacher has many students, what would be the best way to design my database table?
I was thinking of creating a new table and just putting the student/teacher ids in it:
For example, if teacher Tyranno Saurus (id 2) has the two students in the table above linked to him, I would make a table like this:
pk_id | teacherid | studentid
1 | 2 | 1
2 | 2 | 3
That way, I would know that teacher Tyranno (id 2) has two students, namely the student with userid 1 and userid 3.
Then again, I have never really worked on anything like this so I was wondering if anyone could give me some insight about this and if it's possible to do this in a better way.
I'm building my app in PHP (CodeIgniter) with MySQL; if that's of importance.
Thanks a lot.
If a student has zero-or-one teacher coaching them, then I would suggest adding a CoachID column to the student table that is a foreign-key to that particular teacher. The intermediate table you've suggested doesn't do anything to simplify this simple relationship, it actually makes it that little bit more complicated.
If you were tying students to classes (where each class has multiple students and each student takes multiple classes) then an intermediate many-to-many mapping table would be a must.