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 want to create a program where a person will be able to save his schedule.
For example a doctor will be able to save an appointment.
I want to save every appointment in a mysql database. So I need to create a calendar/appointments table. In every appointment I want to save these information:
day
month
year
start (hour)
finish (hour)
participant (the patient)
I was thinking of creating a big table with all the possible appointments for some years (ex. 20 years) and leaving the participant column empty, meaning there is no appointment. If an appointment is made the the participant field will be filled.
Is there a better way of doing it? Can someone provide some guidelines and if possible an example? I want to keep it as simple as possible.
table appointments
--------------------
id int (primary key, auto_increment)
participant_id int (foreign key to persons table)
starts datetime
ends datetime
Then only save the real appointments and not empty ones. Storing fakes is never a good idea.
Related
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 12 months ago.
Improve this question
I am trying to create a database for an office which have 15 different departments, trying to issue tickets for public who access 15 different departments, I need to start the serial numbering for each department separately! is it possible to have just a single table? or do I have to have separate table for each department? and also the ticket numbers table must be reset everyday at midnight and the very next day, Ticket numbers for each and every department should be started from ticket number 1!
Please help me guys! You guys are best helper for a fresher like me
Thank you
you can do in a single table but in that case you will not have to make any primary key or unique key ..thats not a proper way so you should create two separate table one for department and second for ticket_issue and in 2nd table take dpartment_id as foreign key and a separate field for serial number(Note:don't use id as serial number)
to generate serial number get previous serial number from 2nd table for current department and increase 1 on them for next
and for clear data every night you can run a chron job
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 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 a question about database design, I'm wondering how do you go about saving daily user data.
For example I have a table called Accounts
structure is accountID, accountName, DailyScore, WinRate
how can I keep track of DailyScore and WinRate for each day. Do I keep creating tables named after a date or is there a better way.
Accounts has info about each "account" -- account_id, name, etc. This table is rather static -- you occasionally add a row, and sometimes change something.
Scores has new rows every day -- account_id, date, score, etc. The PRIMARY KEY would have two columns: account_id and date.
Not knowing how winRate is calculated, it is unclear where, if anywhere, it should be stored. Is it calculated from the scores??
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.