Background. Requirement: it is not based on the calendar month. How can we determine whether it is continuous sign-in? Then, how can we design the database... background.
Requirement: it is not based on the calendar month.
How can we determine whether it is continuous sign-in?
Then, how should we design the database? Because we didn't sign in based on the calendar month. If we sign in consecutively, we would all be cross-month.
Reply content:
Background.
Requirement: it is not based on the calendar month.
How can we determine whether it is continuous sign-in?
Then, how should we design the database? Because we didn't sign in based on the calendar month. If we sign in consecutively, we would all be cross-month.
Record the date of one person for 1st consecutive days and the date of the last day, and determine whether the person is consecutive when signing in. Consecutive days can be calculated. If not continuous, reset the date of 1st consecutive days and the last day to the current sign-In date.
If you need to sign in, we use a table to record it. It can be recorded by month, that is, every month, or by year. If it is recorded by day, the data volume is too large and there is no need for it.
This database is designed to be too complex. In fact, the logic judgment of the sign-in system is very important. I just made one a few days ago. I only need to format the time and remove the time minutes and seconds, such as 20150907. Then I only need to judge whether the time records of the last few days are adjacent.
One field records the number of consecutive sign-In times, and one field records the last sign-in time!
Sign in each time
JUDGE: Check whether the last sign-in time is one day in the middle of the current sign-in time
Yes:
Sign-In times + 1;
No:
Sign-in Count = 0
The last check-in time of the update is the current time;