Как спроектировать небольшую БД и «правильно» сохранять дни недели?

Question

[web_dev]

Здравствуйте, проектирую небольшой сервис. Буду пользоваться услугами ORM. Хочется подойти качественно к изначальному определению сущностей.

Суть сервиса - можно создавать цели, в целях можно создавать действия, соответственно действия можно выполнять или разово (SingularFrequency), или многоразово (SeveralFrequency), если многоразово, то можно указывать в какие дни.



1. Как корректно спроектировать выбор сохранения между двумя таблицами?
2. Как мне корректно работать с "днями недели"? Создать отдельную таблицу или сохранять как список int-значений?

Прошу прощения, если вопросы чуток неточные.
Заранее спасибо за советы.

Answer 1

[shagguboy]

хранить как обычную дату, пользовать функции типа
dev.mysql.com/doc/refman/5.5/en/date-and-time-func...

Comments

[web_dev]

Наверное я все-таки плохо объяснил... Мне нужно не один день хранить. Мне нужно к примеру хранить 2 или 3 дней. К примеру я хочу делать это упражнение во вторник и четверг и субботу. Та функция сохраняет только один день.

Answer 2

[Rsa97]

Храните как
`weekdays` SET('0', '1', '2', '3', '4', '5', '6')проверяйте через
FIND_IN_SET(WEEKDAY(NOW()), `weekdays`) > 0

Comments

[web_dev]

Спасибо, а не подскажете по первому вопросу? Там у меня на форме "radioButton" и от выбора флажка зависит какие данные и в какую табличку сохранять.
И вопрос к вашему ответу - а не напишете в двух словах, как будут выглядеть связи между таблицами. Будет ли в этом случае придержано все степени "нормализации БД"?

Answer 3

[Rsa97]

По первому вопросу - я бы сделал так:

Такая связь позволяет прикрепить к одному действию несколько расписаний. Для разовых заданий поле `weekdays` не задаётся. Поле `nextTime` устанавливается при создании расписания и позволяет выбрать все действия, который нужно выполнить, даже если были просрочены. После выполнения действия поле `nextTime` можно выставить в NULL, если `weekdays` пустое, или установить время следующего выполнения задания.

Answer 4

[web_dev]

@Rsa97 Все-таки вы меня чуток не правильно поняли. Вот, я сделал небольшую. зарисовку, так уже должно быть понятно 100%. )) Спасибо за подсказки.

Comments

[Rsa97]

У Вас негибкая схема получается. Какие-то действия могут быть завязаны не только на день недели, но и на время, например посещение курсов. Действие при этом одно и то же, а вот время может быть разным, скажем пн, ср 18:00 и пт 17:30. По вашей схеме придётся создавать два действия, по моей - одно действие и два привязанных к нему расписания.

[web_dev]

Мы наверное опять не понимаем друг друга. ))) Привязки по времени нет. Я сохраняю только время сохранения или изменения это информация только для меня. Привязка идет только по дате. И это просто список, список не динамический. Тоисть просто отображать информацию. Которую можно редактировать, удалять.

[Rsa97]

Тогда вообще нет смысла в отдельных таблицах. Просто в таблицу действий добавьте поля для даты и дней недели и ставьте в NULL неиспользуемое поле.

[web_dev]

Я же специально для лучшего понимания нарисовал рисунок. Сущность "Цель" должна быть. У нее есть отдельное имя и отдельная дата. Также цель может существовать и без действий. Она не то же что и "действия". действия принадлежат цели.

[Rsa97]

Я говорю не про Цели и Действия, а про Действия и Расписание. Если у каждого Действия может быть одно и только одно Расписание, то не надо создавать лишние сущности.

[web_dev]

Да.
Ну почему лишние?
Вот посмотрите разовое действие содержит вот такие поля:
- айди;
- метку "до/в" тоисть до такого-то дня или в такой день;
- день;

Многоразовое действие содержит:
- айди;
- "раз в неделю/месяц/год" частота повторений;
- amount - сколько раз в "неделю/месяц/год";
- день начала;
- день окончания;
- список дней недели в которые нужно делать определенное действие.

Я не нахожу эти сущности похожими. Я интересовался, как бы корректно определять табличку в которую нужно сохранять, и как-то обозначить, чтоб различать - это разовое действие, а это многоразовое.

[Rsa97]

Потому, что одноразовое действие можно представить как многоразовое со следующими атрибутами:
Частота повторений: один раз
Количество повторений: одно
День окончания = дню начала
Список дней недели - пустой
Сразу упрощается логика работы с базой.
Нормализация же базы - не самоцель, а одно из средств поддержания структурной целостности базы. Она не должна возводиться в абсолют и использоваться в ущерб остальному.