Общие указания:
- Количество запросов к базе должно быть минимальным.
- Можно использовать битрикс как фреймворк. Или можно сделать без битрикса, но в этом случае можно использовать только готовые компоненты (не фреймворки), например ORM, подключая их через Composer.
- Решение выложить в публичный репозиторий на github или bitbucket и прислать ссылку.
- Код оформить в соответствие с требованиями PSR-2.
- В коде должны присутствовать комментарии, разъясняющие реализацию.
Исходные данные:
- Пользователи системы могут отмечать начало и окончание рабочего дня. Записи хранятся в таблице workday:
create table workday
(
id int auto_increment
primary key,
profile_id int not null, # id пользователи из таблицы profile
date_start datetime null,
date_stop datetime null
);Кроме того пользователь может приостановить рабочий день. Записи о приостановке хранятся в таблице workday_pause
create table workday_pause
(
id int auto_increment
primary key,
workday_id int not null, # id рабочего дня из таблицы workday
date_start datetime null,
date_stop datetime null
);Пользователи хранятся в таблице profile
create table profile
(
id int auto_increment
primary key,
login varchar(255) not null,
name varchar(255) null,
last_name varchar(255) null,
offset varchar(10) null # смещение часового пояса в формате +0300
);Журнал опозданий - таблица lateness
create table lateness
(
id int auto_increment
primary key,
profile_id int not null, # id пользователи из таблицы profile
date date not null # дата опоздания
);- Во все таблицы пишется время в часовом поясе сервера.
- Пользователи могут находиться в разных часовых поясах. Смещение часового пояса относительно UTC кратно часу, случаи смещения на пол часа не рассматриваем.
Реализовано в виде модуля битрикса. При установке разворачивается описанная структура таблиц, для таблиц описаны ORM-сущности. Указанные действия реализованы в виде actions единственного контроллера в модуле. Задачи выполняемые по крону в виде двух функций, "заточенных" под штатные агенты битрикса. Из-за ограниченности возможностей query-buildera в битриксе не удалось внедрить в JOIN ON кастомное сложное условие (не уверен что вожножно, вообще), поэтому реализовано в виде прямого запроса к БД.
Замечу, что столь сложные запросы пришлось собирать для выполнения первого пункта задачи о минимальном числе запросов.. Меньше, практически некуда, дальше только через хранимые функции и триггеры СУБД.
В виду отсутствия достаточного времени на реализацию принял некоторые упрощения:
- Не вынесены в файлы локализации сообщения об ошибках в контроллере
- Не следовал принципам SOLID, да и парадигме MVC не очень, логика получилась вся в контроллере
- Не реализовал некоторые проверки
- Прочие моменты, которые готов обсудить по замечаниям