Является ли система бронирования подходящей для Amazon DynamoDB/NoSQL?

Question

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

Функциональность мне нужно:

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

1. Проверка RESTAURANT таблица, если даже размер даты и вечеринки разрешен.
2. Check BLOCKED стол для заблокированных дат (праздники и другие затворы)
3. Посмотрите HOURS стол, убедившись, что ресторан открыт.
4. Проверить TABLEINFO таблица для таблицы в зависимости от размера партии AND сравнить с RESERVATION стол убедившись, что таблица не уже зарезервированы для другого гостя за то же время

Любые предложения или советы по проектированию базы данных DynamoDB особенно hash & range использовать что-то вроде этого?

Или, как вы думаете, База данных MySQL лучше подходит для такого приложения?

Это быстрый дизайн БД, который поможет вам лучше понять, что я пытаюсь сделать.

Answer 1

Я сделал много с реляционными базами данных, и немного с базами данных NoSQL (только так вы знаете, где я иду с). ИМХО, базы данных NoSQL лучше всего подходит для сценариев, в которых один или более истинны:

1. Данные по существу плоские (не много отношений, почти как старый плоский-файл)
2. Там есть определенная запись «родительского типа» с «дочерним» записями, которые достаточно малы или доступны достаточно часто с родителем , чтобы обосновать их вложение в запись.
3. Вам нужна свобода добавления/заполнения полей в разумных пределах. Мне нравится думать об этом как наследование, где каждый элемент в таблице разделяет некоторые общие черты (ID, Name), но разные записи могут иметь разные черты. Например, в онлайн-каталоге товаров могут быть книги, велосипеды и песни в формате MP3. Запись для «книги» будет иметь материал, такой как ISBN, количество страниц, автор и т. Д. «Велосипед» может иметь размер и цвет колеса , а «MP3» будет иметь длину, исполнитель, жанр, и т. Д. Вы никогда не получите все эти вещи в таблице «item» в RDS без каких-либо серьезных перегрузок или оставленных полей. A База данных NoSQL позволит вам хранить всю эту информацию в таблице и только для элементов, которые в ней нуждаются.

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

Это сказало: я сам попробовал бы это с Динамо сначала как опыт обучения. :)