I am trying to create a fantasy football website. I'm trying to work out the table structure and I was looking for advice.
What I have so far:
usertable - > User Info
playertable - > Player Info
userleaguetable - > User League Info
matchtable - > Match Info
clubtable - > Club Info
Then the two tables that will be doing all the work:
scoringtable
Each week a players record will be added to the table, how many goals, how long he played, bookings, man of the match etc.
So that table will get pretty big: num_players * num_weeks
userteamtable
Each week the players on the users team will be added to the table, which player and which one was captain
So that table will (hopefully) get pretty big too: num_users * 11 * num_weeks
Why I was thinking of going this route with it is due to the fact that there will be a full week by week record of each users team, each players points etc.
So that's basically it, what I'm concerned about is table size, I mean if eventually there was 1000 users that would be 10000 rows added to the DB each week
Anyone have any suggestions for me??
Maybe the scoring table should have a row for each week with a unique identifier for the player. That way, in the scoring table you have 1 record per player with say 52 rows representing 52 weeks in the season. Each week you simply find the scoring record based on the unique identifier for the player and update that record with that weeks score.
This way, you're not adding a record every week for every player, you have 1 record per player for 1 season, it may look like this:
Player ID | Season ID | Week 1 | Week 2 | Week 3 | and so on..
For the next season, you add another record but change the season number. In 2 seasons you only have 2 records per player and so on. For example:
Bob the Player (ID 2450), Season 1, Week 1 score = 50, Week 2 score = 100, etc..
Player ID | Season ID | Week 1 | Week 2 | Week 3 | and so on..
-------------------------------------------------------------------
2450-------|----- 1------|---50---|---100--|--150----
Hope this helps you see the rest of your database in a more efficient way. Good luck!
also wanted to mention, if you're storing multiple values per week just store them in this fashion:
HOw many goals: 5
How long he played: 15min
Bookings: 500
Man of the match: 1 or 0
| Week 1 |
---------------
|5,15min,500,1|
Man of the match can simply be a 1 or 0 value, give the 1 value to the MVP and 0's to the rest, in the example above, this player was man of the match as the last value is a 1.
When your PHP reads in the Week 1 data, just explode it using the commas to create an array of the values for each week.
Related
Suppose a table videos
id | name | views
----------+--------------+-----------
1 | Video1 | 52
2 | Video2 | 150
...
For getting the video which is popular/most viewed this week, I could create another table: videoviews
id | foreign_key | viewed_on
----------+--------------+-----------
1 | 1 | 10/12/2018
2 | 1 | 09/12/2018
...
From this table, I can easily get the data for last week/last month etc. That's not an issue.
Problem:
Suppose I have 1000 Videos and Each video gets 100 Views per day.
My videoviews table will have 100000 records each day.
I know this is not the best way to achieve this functionality. Just wondering what is?
I found these on SO but..
How to get most visited posts of the week?
Popular Today, This Week, This Month - Design Pattern
Problem: Suppose I have 1000 Videos and Each video gets 100 Views per day. My videoviews table will have 100000 records each day.
Do you need a complete record of each individual view?
You could, instead, use a counter approach, where you store one row per video per day, and simply increment its value when a new row comes in. This is granular enough to provide useful per-day analytics, without having to store a million rows for a million video views.
Add extra columns called views and start_date on your videoviews table.
On hitting the page with the video, fetch the views, increment, and update where the week starts with start_date.
Only one row is required per week. You can also remove old weeks if you like.
I'm coding an online timetable website which holds all your current subjects you are attending at school and contains slots to write work and it's due date. Mainly for my own personal use, but I guess I could share the URL with a few people when it's completed. Anyway, I have a login / register system set up, linked to a MySQL database. I have the following columns in a table called 'users'.
userid, username, firstname, lastname, password
Before I attempt anything too stupid, I wanted somebody to give an opinion on what I am about to attempt...
I thought I could write some PHP that creates a table for each new user when they sign up. It would contain all their subjects for each day of the week, and once they input their data it would write it to the database and they wouldn't have to edit their information unless they had to (subject change, etc...)
Would a whole new table for each user's subject data be efficient? The data would have two dimensions: The day of the week (x axis) and the periods of the school day where the subjects are situated (periods 1-6 for my school)
Anyway, thanks for reading, opinions on the best way to go around doing this would be helpful. Thank you.
EDIT: Strawberry's suggestion
userid,day,period,subjectid
1 1 1 4
1 1 2 2
1 1 3 5
1 1 4 3
1 1 5 1
1 1 6 7
2 1 1 4
2 1 2 2
2 1 3 5
2 1 4 3
2 1 5 1
2 1 6 7
I have a table which contains shift sign in and sign out times of employees. Each record has AutoGenID, employeeID, start datetime and end datetime. Based on these data i want to find the hours of work for each employee for a given period of time such as a month.
This is not web based but a Mobile and a PC app which can run in offline mode.
The problem is that there may or may not be multiple records for a single employee with overlapping date intervals. This is because an employee can individually sigh in on multiple devices per day and all these entries are added on this centralized database table. Hence there may or may not be overlapping date intervals for a single employee.
For example lets say that user A signed in from his mobile at '2015-07-03 10:51:19' and later signed in again from his PC at '2015-07-03 12:36:14'
At the end of the day he signed off from his PC at '2015-07-03 18:12:29' and signed off his mobile at '2015-07-03 18:19:53'
And Next day he only uses his PC to sign in. So on the database i have the following records.
+----+-----------+---------------------+---------------------+
| ID | EmpID | start | End |
+----+-----------+---------------------+---------------------+
| 1 | EM001 | 2015-07-03 10:51:19 | 2015-07-03 18:19:53 |
| 2 | EM001 | 2015-07-03 12:36:14 | 2015-07-03 18:12:29 |
| 3 | EM001 | 2015-07-04 11:34:52 | 2015-07-04 17:21:43 |
+----+-----------+---------------------+---------------------+
But when querying the data i only need the Hours the employee worked. So I need the first start time and the last end time if the dates are overlapping so that i can calculate the hours. Again this issue is there only for days with overlapping times and there may not be overlapping times for a single employee on some days.
This hour calculation is not for employee salary purposes. Its just to capture the work hour of the user.
So does anyone have any idea on how to do this.
Thanks
Dipen Shah has a point, but sometimes you can't change the way sign-ins are logged. In this case perhaps you can try grouping the table by the date and querying the min(start) and max (end) of every user and date, like this:
select empid, min(start), max(end) from signin group by empid, date(start);
I have created a database and website that will be used by football managers to select their team etc. Once a match has been completed events will be stored in the match_players table. Such events are Goal, Yellow Card, Red Card etc. I have no problem getting this information into php from SQL db.
I need to add up how many times a Goal appears (a '1' is placed in the SQL table) and for what team so that a final score can be displayed. So, for example, if Team A has 1 goal and Team B has 2 then I need to display that. I am trying to count the amount of times that a Goal is registered in the table. Any help will be greatly appreciated.
You can use MYSQL SUM
select SUM(Goal) from match_players where Team="A"
Or you can get the same for all teams by
select Team,SUM(Goal) from match_players group by Team
Why don't you demand this sum to SQL directly?
SELECT SUM(goals)
FROM match_table
WHERE team = 'Barcellona'
This should be much faster also than elaborate all data at "php-level"
If you want this detail for all teams
SELECT team,SUM(goals)
FROM match_table
GROUP BY team
Well if you store a 1 each time a goal is scored, your table looks like this:
TeamID goal
1 1
2 1
1 1
3 1
2 1
2 1
1 1
So you just want a count of how many times a team appears in that table:
select TeamID, count(*) from table group by TeamID
Will give you
TeamID | count(*)
1 | 3
2 | 3
3 | 1
I am developing a personal finance tracker (for fun!) and I have a table of categories. Each category is an entry in the table and at the end of the month they are all duplicated with their relevant balances reset to the start of the month reading for the new month.
Among others, these categories can be of type 'savings' and so have a running total. If I want to retrieve a category or update it then I used the category_id field and this works fine for the current working month but linking months together is breaking my brain. For the savings categories I want to show how the running_total has increased over the previous six months but in my current DB design, categories don't "know" about their previous months as they are created new at the start of each month.
The only way I could currently retrieve the last 6 months of a savings running_total is to search by the category name but this is potentially unreliable.
I have considered adding a field to the table which is "previous_month_category_id" which would work as a way to link the categories together but would be expensive to implement as it would require 6 MSQL operations each time grabbing the "previous_month_category_id" from the result and then re running the query.
If MYSQL can do some kind of recursion then maybe this could work but I feel like there is a more obvious answer staring me in the face.
I'm using Codeigniter and MYSQL but not scared of vanilla PHP if required.
Help on how to do this would be great.
UPDATE 1:
Below is a sample from what the savings category might look like mixed in amongst other categories. At the end of each month the entry is duplicated with the same category_name, type, buget, year, and users_id but the category_id auto increments, the month updates to the new month number and the running total is the previous running_total + the budget. How would I do one database query to retrieve these without using the category_name? As this could change is the user decided to caller it "Bigger TV" at the end of July
+-------------+--------------+------+--------+---------------+------+-------+----------+
| category_id |category_name | type | budget | running_total | year | month | users_id |
+-------------+--------------+------+--------+---------------+------+-------+----------+
| 44 | Big TV | sav | 20 | 240 | 2012 | 8 | 77 |
+-------------+--------------+------+--------+---------------+------+-------+----------+
| 32 | Big TV | sav | 20 | 220 | 2012 | 7 | 77 |
+-------------+--------------+------+--------+---------------+------+-------+----------+
| 24 | Big TV | sav | 20 | 200 | 2012 | 6 | 77 |
UPDATE 2:
I'm not sure I'm explaining myself very well So I'll put some more detail around how the app works and see if that helps.
I have tables called "categories", "transactions" and "users". A category can be one of three types, 1: Cash, 2: Regular Payment, 3: Savings. Think of cash and regular payment types as buckets, at the start of each month each bucket is full and the aim is to take money out of it and make sure there is still a bit left at the end of the month (or at least not negative).
This is fine on a month by month basis and works very well (for me, I have used this system for 2 years now I think). The trip up comes with Savings as they are linked month by month and are more like a big bucket that is added to each month (with a set increment called budget) until it overspills and is then drained (like Big TV would be when you buy it), or taken from a little bit here and there and the aim is to build up an emergency fund (like "When my car breaks down" type thing).
When the relevant information is displayed for each category only the current month is shown for cash and regular as that is all that is important, for the savings however the current amount is also shown but it would be nice to show a small history graph of how it had built up (or depleted) over time. To do this I need some way of searching for the previous end of month states of these categories so that the graph can be plotted but currently I can't work out how to link them all by anything other than the category_name.
I have tried to implement a bit of DB normalisation but this is the first schema I've implemented having known about normalisation so I've probably missed some aspects of it and possibly avoided any over normalisation where it didn't feel right.
Below are my tables:
categories
+-------------+--------------+------+--------+---------------+------+-------+----------+
| category_id |category_name | type | budget | running_total | year | month | users_id |
+-------------+--------------+------+--------+---------------+------+-------+----------+
transactions
+----------------+--------------+--------+------+----------+------------------------+
| transaction_id | description | amount | date | users_id | categories_category_id |
+----------------+--------------+--------+------+----------+------+-------+---------+
they are joined on categories_category_id which is a foreign key
I have always worked off the premise that each category needs an new entry for each month but it seems from the comments and answers below that I would be better off having just one category entry regardless of month and then just calculating everything on the fly?
Although, the budgets can be changed by the user and so for record keeping I'm not sure if this would work also the "deposits" never really happen it is just the category being duplicated at the end of the month so I guess that would need to dealt with.....
The aim of this app has always been to decouple financial tracking from the physical transaction that occur in a bank account and provide a layer over someones finances thus allowing the user to avoid hard to explain transactions etc and just focus on over all cash position. There is no concept of an "income" in this system, or a bank account.
It seems to me like your database design could use some work. I'm still not completely familiar with what you're really trying to do, but my initial thoughts would be to store each transaction as a single row in a table, and then query that table in different ways to generate different types of reports on it. Something like this:
transactions:
+----+---------+--------+---------------+-----------+-------------+
| id | user_id | amount | running_total | datestamp | category_id |
+----+---------+--------+---------------+-----------+-------------+
categories:
+----+------+------+
| id | name | type |
+----+------+------+
Don't increment the categories based on time. Add an entry to the categories table when you actually have a new category. If a transaction could possibly belong to multiple categories, then use a third (relational) table that relates transactions (based on transaction ID) to categories (based on category ID).
When you have a deposit, the amount field will be positive and for withdrawals, it will be negative. You can get your current running total by doing something like:
SELECT running_total FROM transactions
WHERE id = (SELECT MAX(id) FROM transactions WHERE user_id = '$userID');
You can find your total difference for a particular month by doing this:
SELECT SUM(amount) FROM transactions WHERE DATE('%c', datestamp) = '$monthNumber';
You can find the total spending for a particular category by doing this:
SELECT SUM(t.amount) FROM transactions t
INNER JOIN categories c ON t.category_id = c.id WHERE c.name = 'Big TV';
There are plenty of other possibilities, but the purpose here is just to demonstrate a possibly better way to store your data.