I am stuck with a problem. In an app's db, I am having a schedule table which will store user provided schedules. E.g
Daily
Every Week
Twice a Week
Every 3rd (or any user chosen) day of week
Every Month
Twice a month
Every x day of month
Every x month of year
And so on. These schedules will then provide reference point to schedule different tasks or identify their repeat-ance.
I am not able to think of a proper database structure for it. The best I can get is to have a table with following columns:
Day
Week
Month
Year
type
Then store the specified schedule in the related column and provide the type.
e.g Every week can go like 1 in week column and 1 (designated value for repeating whole) or something like that.
The problem with this approach is that this table is gonna be used very frequently and the data retrieved will not be straightforward. It will need calculation to know the schedule type and hence will require complex db queries to get each type of schedule.
I am implementing it in Laravel app if that can provide any other methodology. It's a SAAS app with huge amount of data related to the schedule table.
Any help will be very much appreciated. Thanks
I suggest you are approaching the problem backwards.
Devise several rules. Code the rules in your app, not in SQL. When inserting an event, pre-fill a calendar through the next 12 months with all occurrences of the event. Every month, go through all events and extend the "pre-fill" through another month (13 months hence).
Now the SELECTs are simple and fast.
SELECT ... WHERE date = '...'
has all the events for that day (assuming it is within 12 months).
The complexity is on inserting. But presumably you insert less often than you select.
The table with the event definitions would be only as complex as needed for your app to figure out what to do. Perhaps
start_date DATE,
frequency ENUM('day', 'week', 'month', ...)
multiplier TINYINT, -- this lets you say "every second week"
offset TINYINT, -- to get "15th of every month"
Twice a week would be two entries.
Better yet, there are several packages (in Perl, shell, etc) that provide a very rich language for expressing event-date-patterns. Furthermore, you may be able to simply 'call' it to do all the work for you!
Related
Developers, I am working on a report that I have to display the companies ranking based on some conditions for the date range which comes from front. Ex: last week, I have done that, but now I want to show how many weeks that a particular company be in same rank. If I am checking the past week I have to check the ranking for each week from the year start. If last week first position company and other weeks first position company is same I have make the count as increasing accordingly. When I querying the data for each week using the for loop it is taking around 42s to process and display the data. Also I tried to fetch whole data from first week of the year to current week then I filtered the array but this also takes long time. Can anyone give any other ideas to overcome this? Thanks in advance.
As far as I understand your problem - then storage of aggregated data should help you.
Create a table in the database, let's say "archive_rating", with 3 fields: week_number (let from January 1, 2000), company_id, company_position in your rating. Don't forget the index for the week_number field.
At 00:00:00 every Monday, run a background task that will save the positions for each company to an archive table.
This will allow you not to calculate a rating for each week from the beginning of the year. You will already have it.
First - thanks for your time. My issue lies in my new usage of Access for tracking values from weekly excel reports. Each week I'm given a new excel file with updated values for about 50 employees. These values generally track their performance over 6 different metrics. I've begun to link these excels into an access database to keep and track that data each week. These linked tables are given the name convention of the date that the data is as of - example: 05-05; 05-12; 05-19, 05-26; etc.
My question is - is there a way to build a query to track the change (difference in values) from last week to this week (05-19 to 05-26), automatically? And also taking into account future additions of linked tables so that I don't have to add a piece to the query each week?
In addition, I'm looking to track overall change - first table 05-05 to the most recent linked table (which ever date that's true for, whether it's the end of July, or the end of the year).
Based on these 2 results, I'd eventually build out the query to show every week with their value and in the next column the week over week change (up down or neutral)
I have a table that I use for statistical purposes.
Its columns are id and 1,2,3,..,31 and pivot.
This table gives the number of views on each day for the last 31 days.
1 gives the number of views for yesterday.
14 gives the number of views for 14 days ago.
etc ...
(pivot is just used to calculate the number of views)
I would use a cron job every day to update this table, but how would I go about "shifting" all the values to the side ( value column 15 would become value column 16; new value for column 1; delete value for column 31)
Define a table with only two columns — "date" and "views"
INSERT a new row in the table with the view count for that day when the CRON job runs
Modify your application query to read through this new table over a custom date range, which could be 31 days or anything else either — please have a look at this link to get an idea:
MySQL Query - Records between Today and Last 30 Days
Not really sure how pivot is being used here. However, I'm almost certain that if you're using it to store the sum of the views, it could as well be computed by using SUM() or GROUP BY without having to need a separate column in the table
As far as data archival / removal is concerned, your daily CRON job could be modified to include a DELETE query (as the last step) which cleans up records older than a certain date. Again, you could use the link above to get your "target" date
.
I apologise that this might sound like a little too long a solution to what you've asked for. However, I feel, this approach should help you organise and maintain the table in question in a better way.
I am writing a script which will counts the number of ticket as per as different conditions and store the count in a summary table. I am unable to understand how to structure my table since there will be more than 1 variables.
The script will run every week and with each execution a new week will be added. Once the new month starts and scripts execute, a new month will be added and once new year starts a new year will be added. So in a nutshell I have columns which are also variables. Not sure how to handle it and structure my db.
Have columns Date Service Count.
Like so.
Date Service Count
16 May 2016 Service1 35
Then when you go to display them in the report pivot them as you want. Probably better to make date an INT and either an auto number PK or composite PK of Date and Service.
Wrong approach. Do not splay an array across columns. Instead have rows for the data. This lets you trivially "add" another month.
For displaying, well that is an application problem, no a MySQL problem. Sure, you can write specialized queries to "pivot" the data from rows to columns, but it is messy.
I'm working on an app that is partly an employee time clock. It's not too complex but I want to make sure I head in the right direction the first time. I currently have this table structure:
id - int
employee_id - int (fk)
timestamp - mysql timestamp
event_code - int (1 for clock in, 0 for clock out)
I've got everything working where if their last event was a "clock in" they only see the "clock out" button and visa-versa.
My problem is that we will need to run a report that shows how many hours an employee has worked in a month and also total hours during the current fiscal year (Since June 1 of the current year).
Seems like I could store clock in and outs in the same record and maybe even calculate minutes worked between the two events and store that in a column called "worked". Then I would just need to get the sum of all that column for that employee to know how much time total.
Should I keep the structure I have, move to all on one row per pair of clock in and out events, or is there a better way that I'm totally missing?
I know human error is also a big issue for time clocks since people often forget to clock in or out and I'm not sure which structure can handle that easier.
Is MySQL Timestamp a good option or should I use UNIX Timestamp?
Thanks for any advise/direction.
Rich
I would go with two tables:
One table should be simple log of what events occurred, like your existing design.
The second table contains the calculated working hours. There are columns for the logged in and logged out times and perhaps also a third column with the time difference between them precalculated.
The point is that the calculation of how many hours an employee has worked is complicated, as you mention. Employees may complain that they worked longer hours than your program reports. In this case you want to have access to the original log of all events with no information loss so that you can see and debug exactly what happened. But this raw format is slow and difficult to work with in SQL so for reporting purposes you also want the second table so that you can quickly generate reports with weekly, monthly or yearly sums.
Is MySQL Timestamp a good option or should I use UNIX Timestamp?
Timestamp is good because there are lots of MySQL functions that work well with timestamp. You might also want to consider using datetime which is very similar to timestamp.
Related
Should I use field 'datetime' or 'timestamp'?