NoSQL хорошее решение для ежедневных данных?

Question

Я разрабатываю приложение для ресторана, и для отдельных гостей будут ежедневно заказываться. из-за этой ежедневной базы данных я думал использовать базу данных NoSQL, например MongoDB, чтобы избежать большого количества объединений в реляционной базе данных (например, прием пищи на определенный день определенного гостя). Другие данные, такие как гостевые данные (имя, фамилия ...), будут храниться в реляционной базе данных. Как вы думаете? Является ли база данных NoSQL хорошим решением для такого рода проблем?

спасибо

Answer 1

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

Базы данных в стилеMongo предлагают ряд преимуществ по сравнению с традиционными СУБД, но эти преимущества действительно существуют только в таких областях, как:

• обработка / обработка огромных (масштабируемых в сети?) объемов не особо структурированных данных
• обеспечивает очень очень быструю производительность на более дешевом оборудовании
• обеспечивает простую кластеризацию для максимального времени безотказной работы

Приложение, которое вы описываете с другой стороны, вряд ли нуждается в пуленепробиваемом времени безотказной работыи также вряд ли понадобится быстро обрабатывать / хранить большие объемы данных.

Ваши данные звучат очень структурированно с четко определенными отношениями, и даже очень загруженный ресторан не собирается производить объемы данных, которыеоправдал бы разбиение / кластеризацию в стиле MongoDB.

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

Answer 2

Я использую и MySQL, и MongoDB для своего приложения. Посмотрим правде в глаза, как бы я ни старался, мне все еще нужен был какой-то тип запросов на соединение. В Mongo это означало два обращения к БД, но, поскольку это было так быстро, я не потерял производительность. Я сохранил информацию о сеансе пользователя в MySQL и использовал Mongo для хранения информации о пользователе. Что мне нравится в этом, так это гео-пространственная особенность.

Answer 3

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

Если ваша модель данных соответствует параметрам MongoDB (без JOIN, встроенных документов, ссылок на базы данных), тогда попробуйте.

http://www.mongodb.org/display/DOCS/Schema+Design

Кроме того, Google для "Mongodb Schema Design" ... множество полезных слайдов и блогов в ближайшее время.