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 yesterday.
This post was edited and submitted for review yesterday and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
I am developing a website for Exams / Test for Students.
We will have student table (student id) , question table (question id, 4 options, correct option)
However for recording the results of students taking an exam, if we create table that has
student id
question id
selected answer
But the challenge is volume. Expecting 1000 students and 200 questions.. If each student does exam once, it will create 200000 records. Assuming they will be practicing exams multiple times, the rows can go to millions very quickly. This may make data retrieval very slow (for showing in each user profile).
Any suggestion how to manage it ? or should we use different type database (nosql rather than mysql).
thanks
the details are provided above
Look into indexing for your tables. This will improve retrieval speed.
Good reference: http://www.tutorialspoint.com/sql/sql-indexes.htm
Two important factors are:
Speed of your server
SELECT statement has minimal conditions and joins. I would spend some time figuring out some good, clean, and optimized SELECT queries your server could use to retrieve the data.
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 4 years ago.
Improve this question
I'm developing a simple application where users can keep track of their weight history.
I have the following tables:
For the purposes of this demonstation, I will be using user id of 5.
When I want to save a users weight history I do this:
INSERT INTO userWeight (userID, weight) VALUES (5, 76)
This saves the weight into the database.
When I want to retrieve weight history for a specific user I do this:
SELECT weight, timee FROM userWeight WHERE userID = 5
My question is, this seems like a funny way of doing things. Is there a better database design I could use?
With this design, the weights for all users gets stored in a single table, is this the correct approach?
Thank you.
Your design is correct because it implements a one-to-many (1:M) relationship between a user and many weights taken at different times.
A simple search confirms this arrangement. For instance, this One-to-many relationship article, or the Wikipedia definition.
Using this model allows you to get a series of weights from a specific user and sort them by time. An implementation where weights are saved on the user table would be incorrect because the number of columns in the user table would have to grow every time a new weight is added.
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 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 5 years ago.
Improve this question
I'm working on creating a database for a gym to track the members info. I want to be able to track the times that people go so you will be able to see when it is busiest. I'm not sure how to go about this. Do I need to make a new table for the information of when a member goes or do I add it into the members or gyms table?
I would add this to a different table. You could make a new table with user_id which is the same as the users ID in the user table. It would then be quite easy to tie the visits to the users, if that’s a point.
Create a visits table with the following columns
visitId
memberId
gymId
entryTime
exitTime
The GymId column may not be required if your member is linked to a gym but it depends on your requirements
Think in terms of "domain" models. From your question it appears you already have Member and Gym models.
I suggest introducing an Attendance model.
Attendance
- UserId
- CheckInDateTime
This would translate to a new database table called "attendance" with the corresponding columns.
In order to see when is the busiest time - I would execute a "select count" statement on the attendance table and "group by" the check_in_date column (truncate the time portion).
A note on persisting datetime values. It is recommended to store the datetime value in UTC timezone. Then you can have your application convert the timezone accordingly when viewing the data.
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 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.