Какую организовать структуру таблиц, если требуется реализовать идею ведения типов какой-то сущности?
Друзья, заранее прошу прощения за, возможно, глупый вопрос, но задача следующая. Имеется таблица 'schedules' и несколько таблиц описывающие "тип" расписания (schedules_type_per_week, schedules_type_per_month и тд ). Я не знаю как лучше сделать запрос на получение типа расписания, если скажем известно что тип может быть только один (т.е если есть расписание по месяцу, то в других таблицах записи по этому расписанию нет). И вот как-то этот костыльный момент что "типа расписания в других таблицах нет, если есть в одной" не очень мне нравится... Посоветуйте, пожалуйста, что-нибудь или подкиньте идею. Заранее благодарю
Какие атрибуты имеют таблицы schedules_type_per_week, schedules_type_per_month; в чем их отличие?
Есть подозрение, что на этапе проектирования БД упустили возможность сделать все по науке, и теперь структура БД заставляет писать неординарные решения.
Что-то много сущностей.
Если структура описывает способ хранения записей регулярных действий, то достаточно таблиц: schedule, schedule_type, schedule_log и schedule_status.
// таблица расписания заданий
Каждая запись описывает задание, когда его начинать и с какой периодичностью
schedule
(
# id, // идентификатор задания
* type_id, // тип регулярности задания
* device_id, // устройство
* client_id, // клиент
* create_date, // дата создания задания
* begin_date, // дата и время первого действия задания
o end_date, // дата окончания задания (может отсутствовать и быть не кратна регулярности)
* active // выполнять ли задание
)
// Таблица-справочник типов периодичности
schedule_type
(
# id,
* name
)
// Таблица - логи задач
Когда происходило очередное выполнение задачи, и куда сложили результат (файл восстановления)
schedule_log
(
# id, //
* status_id, // статус выполнение действия
* schedule_id, // по какому периодическому заданию выполнялось это действие
* begin_date, // дата и время непосредственного начала выполнения действия
o end_date, // дата и время окончания данного действия, если отсутствует, то действие сейчас выполняется
* backup_name, // результат выполнения
o error_info // сообщение об ошибке в случае краха выполнения действия
)
// Статус выполнения действия задания (выполняется, завершено успешно, завершено с ошибкой)
schedule_status
(
# id,
* name
)
Как работать с этой структурой?
Есть запись регулярного задания в schedule.
Смотрим, активно ли оно по атрибуту active, если активно, то проверяем, что текущее время сейчас в периоде [begin_date, end_date] выполнения этого задания. Если да, то смотрим логи schedule_log, смотрим на атрибут schedule_log.begin_date и выясняем, когда последний раз выполняли задание: день, месяц, год назад. Если интервал больше, чем положено по типу регулярности задания, или его никогда не запускали, то запускаем его.
alexalexes,
Структура базы у меня на много больше. Это та часть, которая отвечает за хранение расписаний. Смысл в том, что запускается некий worker в 9 утра каждый день, и проверяет некоторое действие в зависимости от расписания. Будет брать это задание worker сегодня или нет, зависит от расписаний. Сам результат выполнения храниться на удаленном сервере, там я ищу запись о том, что работа была выполнена например во "вторник 11:00" и веду у себя report
Средний
