Дизайн стола DynamoDB для рабочего времени - PullRequest
Новая
       14

Дизайн стола DynamoDB для рабочего времени

1 голос
/ 23 апреля 2020

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

Я видел много примеров и схем для разных баз данных, но просто не могу найти правильный дизайн таблицы для DynamoDB.

Вот мои требования :

  1. каждый бизнес должен иметь рабочее время по умолчанию (понедельник с 08:00 до 14:00, 16: 00 - 20:00) и специальные мероприятия (26/11/2020 магазин закрыт / открыт с 10:00 до 14:00 в связи с Днем благодарения)
  2. каждый день может иметь несколько продолжительности работы (08:00 - 14:00, 16:00 - 20:00)

Это операции Мне нужно разрешить:

  1. Создание / редактирование рабочего времени для каждой компании (включая специальные мероприятия)
  2. Проверьте, открыта ли компания (или список предприятий) прямо сейчас - предоставив список идентификаторов компаний.
  3. Получите рабочее время (или список предприятий) между 2 датами (например, 23/04/2020 - 25/04/2020), предоставив список рабочих ss идентификаторы и диапазон дат для каждого идентификатора

Что я пробовал:

Определил таблицу, где бизнес-идентификатором является partition key (HASH) и специальные даты / день недели - это sort key (RANGE).

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

Посоветуйте, пожалуйста, какой дизайн стола я должен использовать для этого приложения.

1 Ответ

1 голос
/ 23 апреля 2020

Вам, вероятно, нужно сначала создать свою всеобъемлющую логику c вне DynamoDB, принять решение о том, работает бизнес или нет, и использовать только карьеры в Динамо для подмножества этих логи c.

Допустим, хотя мы используем DynamoDB для запросов в отношении нормального рабочего времени и не учитываем logi c, такие как праздники и особые случаи, вы можете использовать это для фильтрации после доступа к Dynamo. Вы не можете создать один запрос в «Динамо», чтобы ответить на все ваши вопросы, что больше похоже на то, что вы можете сделать в SQL.

Итак, допустим, у нас есть таблица / подмножество значений, которые относятся к нормальной работе день. Итак, у вас есть что-то вроде этого:

Ключ раздела (PK): business, Ключ диапазона (RK): dayOfWeek и атрибуты opens & closes.

Затем мы можем создать 2 GSI:

  • PK dayOfWeek RK opens
  • PK dayOfWeek RK closes

Теперь мы можем сделайте два запроса, если магазин открыт с 14:00 до понедельника:

  • PK == ПОНЕДЕЛЬНИК & открывается <14:00 </li>
  • PK == ПОНЕДЕЛЬНИК & закрывается> 16:00

И собирать только те значения, которые появляются в обоих запросах.

Очевидно, что иметь PK дня, вероятно, не очень хорошая идея, так как у вас будет только 7 разделов. Ну так что ты делаешь? Ну, у вас, вероятно, больше критериев в запросе, чем просто день, например, тип магазина, город, в котором он расположен, и т. Д. c. Это будет означать, что тогда у вас будет PK что-то вроде: city-category-dayOfWeek.

Аналогично, на стороне сортировки вы могли бы хотеть, чтобы магазины с более высоким рейтингом были первым вариантом, поэтому у вас может быть что-то вроде: {rating}-{open} & {rating}-{closes}.

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

...