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 5 years ago.
Improve this question
I am building a mysql database to store golf scores.
I am not sure on the best approach to store the round information.
Each round is made up of either 9 or 18 holes and for each hole I need to store
Hole id
Number of shots
Stableford points
Green in regulation
Fairway hit
Number of putts
Number of penalty shots
My question is should I have one huge table, that stores all of this. Like a rounds table. and have the above 7 fields 18 times for each hole.
Or should I have a smaller rounds table that just contains the date played etc and then another table such as scores that just has the 7 fields, and have multiple rows in that table to make up the complete round?
I guess I am asking in terms of which would perform better and which is the better design?
Thanks
Definitely two tables. First, let's name it rounds will contain data relevant to round itself, such as date, id of the golf terrain etc. The other, let's name it hole, will have 7 aforementioned fields, together with round_id field that will reference round that particular hole belongs to.
Main benefits are clearer design and avoidance of redundant data. If you keep everything in one huge table, each row would need to contain not just fields relevant to the single hole, but also fields relevant to the whole round (date, id of the terrain..) -> same data in many rows, unnecessary. What if you mistakenly enter wrong date? You would have to change it in all 9 to 18 rows instead of only one.
See also:
Normalization in MySQL
Database normalization
Divide your information as much as possible. Otherwise you'll face alot of redundant data.
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 5 years ago.
Improve this question
I'm creating a function that retrieves records based on several different fields and then stores those records so we can query them later.
When querying the records, we're selecting a record to be used elsewhere if it matches the requirements of another set of fields/criteria.
For example:
Returning employee records so that one of them can be selected for a new position (management maybe?) based on fields such as skill set, location, and so on...
The problem
Say I loop through these stored records (in an array or something similar) and I check if the first employee in the array is suitable for the position, then find out they are, so then add them to the position, I'm neglecting the other x amount of employees that have been stored. I feel like this would be an issue because it might turn out that the order in which someone is stored might determine the likelyhood they are chosen for the position.
I thought this might be solved by creating a sorting function to sort the stored records based on the employers preferences (location, salary, availability,...), although I'm not sure how to implement this.
I'm wondering if there is any built in MySQL functions that would help sort the records based on something?
This might be something I might have to figure out on my own, but I thought I'd ask just in case there was anything useful I could use.
I hope the question was clear. If not, please comment below.
Just thinking out loud - won't sorting create the same issue you are trying to avoid - unless you can come up with a weighted score...
create table as employees_to_consider as
select e.*,
availability_score*availablity_factor
+ salary_score*salary_factor
+ location_score*location_factor as weighted_score
from employees e
where -- whatever your criteria is for selection here
order by weighted_score
The real task is deciding how to determine the score for each factor and what the appropriate weight should be.
For example, salary score can be determined by taking the ratio of what the employee is willing to work for by the target. If they match, it can be scored as 50. The number can be increased by the amount the employee is willing to work under the target and decreased by an amount they are over. Salary is pretty important so the factor might be 33%.
Similarly, if the employee lives with 15 minutes, then they can be scored at 75, within 30 at 50, over 30 25. Location is not as important as salary so it is scored at 10%.
Hopefully, you will be able to assign meaningful scores and factors to each measure.
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 9 years ago.
Improve this question
most likely a clueless question but I would like to start off on the good foot:
Despite trying my best, I have actually never really learned to program and I'm kind of "learning as I go" so please excuse me if this seems very obvious to you...
It's more of a suggestion and feedback kind of question rather than pure programming.
My situation is the following:
I'm building a racing game that would receive various inputs from a number of users (through a php website), I am storing that information in a MySQL database, and once a week I would like to process all that information to generate "lap times", which will then create a race (my "output").
Not taking into account the various methods of calculating that output, I need to do two important things which I'm not sure how to begin with at all :
1) Storing the race information for every user (lap time per lap, fastest lap, race position per lap, race position at end of race, award points depending on the position).
Where and how should I optimally store those informations ?
I have created a race DB with a unique identifier that auto increments, I'm thinking I will generate 1 set of data for each race, so should I store all the information pertaining to that race in there ?
Would I then create a data row (with type time?) for the lap time informations (1 row for lap1, 1 row for fastest, etc... ?)? But how would I know which user (I have a unique userID for each) did which lap (how would I assign the userID to the lap time)?
2) At the end of the race I need to award points depending on race position at the end, should I just compare total lap times (additional row?) and sort by lowest first ? The points data would be stored in the user DB ?
I appreciate any input you might have for the modeling of this project !
Drop every lap_round, lap_time and position in the DB and add a user_id and a race_id.
Afterwards query the laps. That way you can tell which is fastest overall, fastest per user, time per lap and much more.
To get the position query the db for the last lap. It holds its position.
Points are user based, so put them in the user table. Just add. But if you want to tell how many points were added per race than make a seperate table points (user_id, race_id, points)
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 9 years ago.
Improve this question
I have just started PHP programming and have the following scenario;
My contact list is saved in mysql database (Fname, Lname, phone) = done
Take user input as imagining it taking from a mobile keypad .i.e. 'abc' corresponds to 1, 'def corresponds to 2 etc.
Let's say user enters "738"...this would correspond to 'PET' and so will 'REU'.
What the php code is suppose to do is get the user input in the form of digits and search through the mysql database going through the last name to see if it corresponds to any of the name and finally list those contact(s). However, since 'SET' is also a valid combination of 738 BUT if it does not exist in the database, it will not get displayed.
Question: how can i take the input in digits and generate all possible combination to match against the database? I guess i will have to use arrays to store the mobile keypad mapping and somehow do the permutations stuff.
Any help will be appreciated.
I would love to hear more about the use case where this is still worth programming in 2014.
If you really wanted to do this, you COULD enumerate all the possibilities and search that way, such as:
222 = AAA, AAB, AAC, ABA, ABB, ABC, ACA, ACB, ACC, BAA, BAB, BAC, BBA, BBB, BBC, BCA, BCB, BCC, CAA, CAB, CAC, CBA, CBB, CBC, CCA, CCB, CCC
Which is 3 cubed (27) possibilities.
However if you have 7 numbers you have 3^7th, or 2187 permutations, which is going to be an ungodly OR LIKE 'AAAAAAA%' chain.
However this method is backwards. What you should do is add a mobile-keypad-name for any name you want to search with this method, and pre-populate it with the representative digits- there will only be one possibility per name.
The SQL lookup is then a straight shot:
WHERE mobile-keypad-name = "2222222";
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 8 years ago.
Improve this question
I'm building a browser game which you can shoot missiles on factories.
This is example of a similar SQL table:
user_ID iron steel metal gold
1 21 30 39 25
2 7 10 25 50
I need each missile to destroy 1 factory.
For example I shoot 10 missile, so 10 factories are destroyed. But I need it to have completely randomly and even.
The problem is if according to this SQL table, if I shoot for example 40 missile on user_ID '2'.
In best case I destroy 10 factories of each kind. But how can I do it when I don't know if there is enough of each kind?
First, divide the number of missiles by the number of factory types that have at least 1 factory. If all the types have at least this many factories, subtract this from each column.
If any of the types have less than this, they'll be totally wiped out. Reduce them to 0 and subtract their original totals from the number of missiles. Then start again, using just the remaining missiles.
Repeat this until you use up all the missiles or all factories are wiped out.
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 8 years ago.
Improve this question
I need to implement a mechanism with the following abilities:
Add new users
Delete a user
Enable a user
Disable a user
And also let the administrator to select a period of time and then show which users were:
Available in the system at that period
Enabled
Disabled
The result should be for that exact period of time.
Note: A user might be enabled or disabled several times and I need to keep track of every single change. So, if the user is disabled between the March 1th and April 2nd, it should not be appear in the results if the administrator querying a time period between March 1th up to April 2nd, but it should be included in the results if the administrator querying any other period of time.
Also the tricky part is to contain the usesr who has been added, deleted, enabled or disabled before the period that administrator querying.
I don't have any set up for now, so I'm pretty up for any idea. Actually I'm thinking of a mechanism like a log which you can query that later, but it should be really fast because I need to use it in many places.
Also I prefer to do everything in a single MySQL Query, however the PHP combination/interaction is also okay.
Per commentary, look into Slowly Changing Dimensions:
http://en.wikipedia.org/wiki/Slowly_changing_dimension
An additional top, having implemented this a few times myself. Personally, I've found it better to have two sets of tables, rather than a single one.
Think of the main one as a normal table with an extra rev (for revision_id) field:
id, rev, field1, field2
rev is a foreign key to the revisions table:
id, rev, field1, field2, start_date, end_date
And if you ever use Postgres to implement it, I'd advise to look into the tsrange type instead of two separate start_date and end_date types.
The main table vs history tables makes "normal" queries perform better and much easier to index.