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

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

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

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

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

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

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

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