Правильная структура для хранения посещаемости?

Question

[Влад]

Добрый день!

Есть табель посещаемости сотрудников компании. Необходимые поля для хранения: Объект, Сотрудник, Кол-во часов, Тип пропуска дня(болен, прогул и т.д.), Тип рабочего дня (по часам или по объему), Дата.

Скажите пожалуйста как лучше организовать структуру таблицы для правильного хранения этой информации. Я предполагаю два варианта:

1. Каждый день хранить как отдельную запись, но тогда в месяц на 1000 сотрудников будет 30-31 тысяча записей, а за год примерно 370 тысяч.
   
2. Формировать за месяц json массив данных сотрудников и получается 1 запись в месяц, только с запросами уже беда получается. Но для отчетов или расчетов доставать данные не составит проблем.
   

Вариант зависит от личного предпочтения или один из них наиболее верный?

Спасибо!

Answer 1

[Константин Цветков]

1С ЗУП. Если "посещаемость" (работать не обязательно) нужна для расчёта зарплаты.

Максим Кузнецов:

рабочего графика

И так, "структура для хранения посещаемости" не является первичной для построения модели данных. Первичной является структура рабочего графика, или учебного плана, или графика работ (для "свободных работников") и прочее. На основании задания строится его выполнение, то есть "посещаемость".

Answer 2

[Максим Кузнецов]

Не очень понятно, откуда берётся и для чего дальше нужна хранимая информация, как долго она хранится. Ещё не ясно, какую СУБД используете. Объёмы у Вас не очень большие.

Когда мы делали учёт рабочего времени для ПАК "Посетитель", там было всё по честному: регистрировались все события входа/выхода, в том числе между контурами внутри организации. Далее эти события обрабатывались, строилась витрина с учётом плана и факта. Была своя логика определения нарушения рабочего графика, так что опоздание на 5 минут, например, прощалось, но регистрировалось и т.п. Допускалось 15 минут в течение дня на "покурить". Вот со всем этим, с настройками и оперативными данными, с витринами обработанных данных, у нас нормально справлялись и MS SQL, и Firebird, и Postgres. Данные хранились лет 5.

Answer 3

[Артемий]

Можно Elastic Search использовать т к база не транзакционная. Масштабируется под объем легко. Хотя на репликации и шардинге можно реляционную сделать. А можно тупо архивы в файл писать и чистить базу. Табели нужны максимум лет пять. В JSON не стоит складывать, по записям современные базы легко тянут 500 000 записей в год.