I'm building an 'events' table that will show the events for that particular day.
However, since most events start late in the evening and end early in the morning I would like to know as to how I should plot and retrieve the data. Let's say that and event day starts at 6:01 AM and ends at 6:00 AM. Is the time dependent on the server time? Can I change it to some other GMT time? How would the time table look in the mysql database?
Thank you!
I would have a table like this:
Event
======
EventID
Name
StartTime
EndTime
StartTime and EndTime would be stored as UTC dates. With this schema you can query however you like, and present the time for whatever time zone you like, but it keeps things consistent and well performing. You would want to index EventID, StartTime, and EndTime.
Related
I am creating an attendance system and i want to automatically change the subject based on the time of the day. I have a table consist of subject name, start time, end time and its day. I have a question, is it possible to automatically get the value of a row based on specific time and day?
For example the current time is 12:45 PM and the day is Tuesday. This is my sample table. Then the output will be Principles of OS.
in mysql to get the name the current day use
DAYNAME(date)
and compare it to your sub_day column in selection
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!
I know pages and pages have been written on this topics, however, I need to clarify this issue, and be sure I'm doing what is sensible.
The users of my app can be in any part of the world. I log a number of events/actions a user performs on my app. I want to be able to see what events/actions a user made in it's own time zone, or a timezone of my choosing.
At the moment, my app is sending the date and time of the event in UTC in the format "YYYY-MM-DD HH:MM:SS" and also, in a separate field, the time zone offset in minutes (e.g. -120 or +60).
When I get the events, I store them in MySQL in the following way: I use a DATETIME column to store the date and time of the event as is; I use an INT column to store the offset.
When I want to do a select and get back the event in the user's time zone, I just do:
SELECT cdate + INTERVAL tz_offset MINUTES FROM events WHERE uid=123;
I believe this is the best option for me, and offers versatility.
What do you think?
Thank you!
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'?
I want to grab records from a table based on the day of the month the record was created.
This information is stored in a Unix timestamp. During testing I created new test records and threw in some timestamps for specific times that I had converted to timestamps using an online converter. I used...
01/29/2010-02:00:00
Right now I'm using...
FROM_UNIXTIME(timestamp, '%d') == 29
This should work for all times on the 29th day of every month. But it is calculating the timestamp to be 5 hours behind the actual value of the timestamp. When I just run a FROM_UNIXTIME on the timestamp it returns 01/28/2010-21:00:00. I was hoping someone could give an explanation for this, if there is an easy fix or should I just code the program to expect the timezone to be a factor.
The FROM_UNIXTIME function automatically converts the datetime to the current timezone.