Имеется предварительная схема БД (участок схемы):
Краткое описание предметной области:
Имеется таблица
Schedule, в которой энергетиками (юзерами) в разных городах устанавливается расписание включения и отключения уличного освещения (через web-морду, разумеется).
Юзеры могут создавать расписание как для города целиком, так и для групп линий освещения и даже для отдельных линий. Поэтому таблица
Schedule ссылается по FK на "область видимости" для установленного расписания. Расписание, установленное для линии, приоритетнее расписания, установленного для группы, которой эта линия принадлежит (линия в конкретный момент времени может принадлежать только одной группе).
В таком же отношении находятся группы и города.
Мне не нравится табличка
SkopeForSchedule. Не нравится тем, что одну "область видимости" для расписания можно несколькими способами. Например, записи (line_id = 1, group_id = 1, city_id = 1), (line_id = 1, group_id = 2, city_id = 1) и (line_id = 1, group_id = 10, city_id = 111) представляют одну "область видимости" – line_id = 1. Напоминаю, что значение в line_id приоритетнее значения в group_id, а значение в group_id приоритетнее значения в city_id.
Второе, что мне не нравится в этой схеме. Юзеры могут создавать и удалять города, группы и линии. При этом, когда юзер удаляет, например, группу, то соответствующая запись в таблице
Group не удаляется, а помечается временем удаления в поле
deleted. Может получится, что сначала какая-то линия принадлежала одной группе, а затем стала принадлежать другой группе. То есть в историческом контексте таблицы
Group и
Line связаны как M:N. Аналогично связаны таблицы
City и
Group. Поэтому для этих двух связей нужно добавить таблички M:N.
Насколько вообще такая схема хороша и что в итоге нужно сделать с таблицей
ScopeForSchedule?
Простой
Средний
