Correct structure to store attendance?

Question

Database design

Good afternoon!
There is a report card attendance of employees of the company. Required fields for storage: Object, Employee, Number of hours, Type of day pass (sick, absenteeism, etc.), Type of working day (by hours or by volume), Date.
Please tell me how best to organize the structure of the table for the correct storage of this information. I'm guessing two options:

1. Store every day as a separate record, but then there will be 30-31 thousand records per month for 1000 employees, and about 370 thousand per year.
   
2. To form a json array of employee data for a month and you get 1 record per month, only with requests it's already a problem. But for reports or calculations, getting data will not be a problem.
   

Does it depend on personal preference or is one of them the most correct?
Thank you!

Answer 1

1C ZUP. If "attendance" (work is not required) is needed to calculate salaries.
Maxim Kuznetsov :

work schedule

And so, the "structure for storing attendance" is not primary for building a data model. Primary is the structure of the work schedule, or curriculum, or work schedule (for "free workers"), and so on. On the basis of the task, its implementation is built, that is, "attendance".

Answer 2

It is not very clear where it comes from and why the stored information is needed further, how long it is stored. It is not yet clear which DBMS you are using. Your volumes are not very large.
When we did the accounting of working hours for the PAK "Visitor" , everything was honest there: all entry / exit events were recorded, including between circuits within the organization. Further, these events were processed, a showcase was built taking into account the plan and the fact. There was a logic for determining the violation of the work schedule, so being late for 5 minutes, for example, was forgiven, but was registered, etc. It was allowed 15 minutes during the day to "smoke". With all this, with settings and operational data, with showcases of processed data, MS SQL, Firebird, and Postgres coped well with us. The data was kept for 5 years.

Answer 3

You can use Elastic Search because the database is not transactional. Scales to size easily. Though on replication and sharding it is possible to make relational. And you can stupidly write archives to a file and clean the database. Report cards are needed for a maximum of five years. JSON should not be folded; according to records, modern databases easily pull 500,000 records per year.