Схема расписания ежедневных встреч MySQL

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

При регистрации в качестве провайдера им разрешается выбирать дни и часы работы. У них есть флажки html, которые представляют, какие дни они могут выбрать, и как только они выбирают день, отображаются часы (раскрывающиеся списки в angular), как вы можете видеть ниже.

HTML-форма расписания

На стороне MySQL я думаю, что могу иметь таблицу, в которой есть столбец для каждого дня и список, разделенный запятыми, для времени начала, времени окончания, времени обеда и продолжительности обеда.

т.е. провайдер выбирает понедельник и вторник для работы из часов, указанных ниже.

Таблица "Расписание" провайдера

|ScheduleID|ProviderID|Monday  |Tuesday |Wednesday|Thursday|Friday|Saturday|Sunday|
|----------|----------|--------|--------|---------|--------|------|--------|------|
|1         | 2        |09:00am,|10:00am,|         |        |      |        |      |
|          |          |08:30pm,|07:00pm,|         |        |      |        |      |
|          |          |12:00pm,|01:00pm,|         |        |      |        |      |
|          |          |30 min  |60 min  |         |        |      |        |      |
|----------|----------|--------|--------|---------|--------|------|--------|------|

Таблица будет иметь идентификатор расписания и идентификатор провайдера, который связан с таблицей «провайдера», чтобы связать провайдера с его расписанием.

Или так лучше?

|-------------|-------------|----------|-----------|----------|------------|--------------|
| schedule_id | provider_id | week_day |start_time | end_time | lunch_time | lunch_length |
|-------------|-------------|----------|-----------|----------|------------|--------------|
| 1           | 1           | Monday   | 06:00 AM  | 08:00 PM | 12:30 PM   | 60           |
|-------------|-------------|----------|-----------|----------|------------|--------------|
| 2           | 1           | Friday   | 06:00 AM  | 08:00 PM | 12:30 PM   | 60           |
|-------------|-------------|----------|-----------|----------|------------|--------------|
| 3           | 2           | Tuesday  | 06:00 AM  | 08:00 PM | 12:30 PM   | 60           |
|-------------|-------------|----------|-----------|----------|------------|--------------|

если не опубликовать что-то, что есть


mysql html database-schema jsonschema
person figuer25    schedule 08.03.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Прежде чем я расскажу о том, как, по моему мнению, вы должны структурировать свой Provider 'Schedule' Table, пожалуйста, не забудьте в будущем избавиться от лишнего.

Подробнее о чуши здесь.

Возможно, вам будет удобнее внести следующие изменения:

  • сделайте все заголовки столбцов в нижнем регистре, так как это может предотвратить ошибки, если вы попытаетесь запросить свою базу данных другим способом.
  • изменить scheduleId на id
  • Вместо семи столбцов, по одному на каждый день недели, вы можете просто поместить weekDay столбец, в котором будет храниться значение этого дня недели.
  • Затем создайте столбцы для startTime, endTime, lunchTime и lunchLength
  • Наконец, создайте столбец scheduleId, который связывает воедино все строки дня недели в чьем-то расписании с одним поставщиком.

Некоторые соображения:

  • Вместо строк "Monday" или "Sunday" в столбце weekDay вы можете вместо этого вставить 0..6, где 0 - воскресенье, а 6 - суббота, чтобы сделать его более совместимым с другими языками.
  • Вы всегда можете просто сохранить scheduleId в этой таблице и создать другую таблицу с отдельными днями расписания и связать их с внешним ключом, но это может вызвать больше проблем, чем стоит
  • Сохраните это lunchLength как целое число, так как это все упростит

Причина, по которой следует максимально возможное разделение данных, заключается в том, что если вы запрашиваете на другом языке, вам может потребоваться выполнить всю дополнительную работу по разделению этих Monday и Tuesday столбцов, если вам, например, просто нужен startTime.

Надеюсь, это либо решение, либо позволяет рассмотреть другой подход.

person EVAL    schedule 08.03.2016
comment
посмотрите, пожалуйста, на мой вопрос. Я добавил раздел ниже, который, как мне кажется, вы имели в виду. Дайте мне знать, если вы это имели в виду. Я думаю, вы имели в виду, что если провайдер сокращает, скажем, с понедельника по пятницу, у него будет 5 разных записей в этой таблице, и все 5 из этих записей будут иметь уникальный schedule_id, но будут иметь один и тот же provider_id, указывающий на таблицу Provider. - person figuer25; 09.03.2016
comment
@ figuer25 Поскольку любой ответ на этот вопрос потребует определенного мнения, правильного ответа нет. Я сделал предложение, основанное на моем опыте работы с MySQL, и на том, что, по моему мнению, может быть полезно, поскольку я не знаю лучшего решения для вас. В настоящее время я автоматизирую составление отчетов с использованием объектно-ориентированного языка, такого как Ruby, поэтому, по моему личному опыту, наличие такой разноплановой информации, содержащейся в одном столбце (то есть отметок времени и продолжительности в минутах), дает мне больше работы. Я также предложил использовать больше столбцов с числовыми идентификаторами, поскольку они значительно сокращают время запроса (в отличие от поиска по строке). - person EVAL; 09.03.2016
comment
@ figuer25 Еще одна вещь: вы можете добавить столбец week_day_id, как я предложил в своем ответе. Другими словами, если вы хотите запросить всех, кто работает с Tuesday, а ваша таблица имеет бесконечное, но счетное количество строк, поиск строки Tuesday вместо id 2 займет намного больше времени. Я также отредактировал свой ответ, чтобы правильно отразить класс Ruby Time. - person EVAL; 09.03.2016
comment
Спасибо, я рассмотрю числовую замену скорости, но у меня уже была логика, работающая со строками. Ранее я разрешал провайдеру вводить свое время на каждый день. Например, они вводят время, скажем, 9-5, и это их расписание на каждый день. Сейчас я обновляю его, чтобы дать им возможность пользоваться почасовой оплатой каждый день. Но я учту. Мне просто не нравится, когда нужно сопоставить 0-6 с Sun-Sat и т. Д. - person figuer25; 10.03.2016
comment
Я решил создать справочные таблицы для будних дней и некоторые другие данные в таблицах моей базы данных. Я рассматривал возможность использования ENUM, но, похоже, есть некоторые недостатки, как указано в этой статье komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil - person figuer25; 15.03.2016
comment
@ figuer25 Спасибо за то, что вы постоянно работаете над решением вашей проблемы и проводите исследования. Я предложил использовать ENUM или TINYINT в зависимости от вашего приложения: раскрывающееся меню на веб-сайте. Вероятно, будет использоваться Javascript или Ruby. Оба используют интервал 0..6 для представления дней недели. В статье, на которую вы ссылались, говорилось, что было бы неплохо использовать ENUM для концепций, которые никогда не изменятся: например, континентов. Я думаю, то же самое можно сказать и о буднях. - person EVAL; 15.03.2016
comment
@ figuer25 Вы также можете посмотреть этот вопрос SO и этот вопрос DbA для получения дополнительной информации. Теперь окончательное решение остается за вами, и я надеюсь, что у вас есть все инструменты, необходимые для выполнения вашей задачи. Если нет, продолжайте обсуждение! - person EVAL; 15.03.2016
comment
Я думаю, что ограничения ENUM отталкивают меня от него. Короче говоря, проще использовать ENUM для будних дней, и, возможно, для будних дней я буду использовать ENUM, поскольку он буквально НИКОГДА не изменился lol Но у меня также есть, например, member_type как часть пользовательской таблицы, которая имеет такие значения, как Client, Provier, этот список может расширяться, поэтому для этого я воспользуюсь справочной таблицей. В целом меня устраивают дополнительные объединения, чтобы избежать проблем с расширением этих списков в будущем. Я обновлю этот пост, скорее всего, когда я закончу и буду знать, какой подход я придерживался. - person figuer25; 15.03.2016
comment
@ figuer25 Еще раз, я предложил использовать ENUM или TINYINT только для дней недели. Это также означает, что, поскольку вы работаете с Javascript, вам никогда не придется устанавливать это соединение (т.е. 0 означает воскресенье), потому что JS уже устанавливает соединение между 0..6 и Sunday..Saturday. Со временем станет яснее, что сохранение дней недели любым другим способом потребует дополнительной работы. - person EVAL; 16.03.2016

arrow_upward
0
arrow_downward

Вот библиотека Java Android, которую можно преобразовать в JavaScript: https://bitbucket.org/warwick/schedule_utils_demo/src/master/

Выполнение кода на клиентском языке избавит ваш сервер от нагрузки, поскольку код планирования очень неэффективен.

Надеюсь это поможет.

person user2288580    schedule 21.10.2018