У меня есть конкретное требование к обработке данных, которое я разработал, как это сделать в SQL Server и PostgreSQL. Тем не менее, я не слишком доволен скоростью, поэтому я изучаю MongoDB.
Лучший способ описать запрос состоит в следующем. Изобразите иерархические данные США: Страна, Штат, Графство, Город. Скажем, конкретный поставщик может обслуживать всю Калифорнию. Другой, возможно, может обслуживать только Лос-Анджелес. Есть потенциально сотни тысяч продавцов, и все они могут обслуживать от некоторых точек (ов) в этой иерархии. Я не смешиваю это с Geo - я использую это, чтобы проиллюстрировать необходимость.
Используя рекурсивные запросы, довольно просто получить список всех поставщиков, которые могут обслуживать определенного пользователя. Если бы он был в Пасадене, Лос-Анджелес, Калифорния, мы бы поднялись по иерархии, чтобы получить соответствующие идентификаторы, а затем запросить назад, чтобы найти поставщиков.
Я знаю, что это можно оптимизировать. Опять же, это простой пример запроса.
Я знаю, что MongoDB - это хранилище документов. Что подходит для других потребностей, я очень хорошо себя чувствую. Вопрос в том, насколько хорошо он подходит к типу запроса, который я описываю? (Я знаю, что у него нет объединений - моделируются).
Я понимаю, что это вопрос длительности строки. Я просто хочу знать, есть ли у кого-нибудь опыт работы с MongoDB. Мне может потребоваться некоторое время, чтобы перейти от 0 до тестируемого, и я хочу сэкономить время, если MongoDB не подходит для этого.
Пример
Местный кинотеатр "А" может поставлять Blu-Ray в Спрингфилде. Сетевой магазин "B" с распределением по всему миру может поставлять Blu-Ray для всего IL. И магазин "C" для загрузки по требованию может поставляться всем США.
Если бы мы хотели получить всех применимых поставщиков фильмов для Springfield, IL, ответ был бы [A, B, C].
Другими словами, существует множество поставщиков, прикрепленных на разных уровнях иерархии.