У меня встал такой вопрос по монго, как я изучаю его не до конца понимаю для каких задач все таки нужна монго. Как я понял создавая срм систему на монго, лучше идти из связки от одного ко многим, Для messanger скорее всего mongo идеально подойдет один пользователь имеет свои настройки(личные данные и т.д) и много chat_Id а отдельные база chat_id хранит всю переписку, приложение и много чего. Но допустим в срм система лучший вариант исходить из реляции верно? или там все строить по другому. База клиентов, где храняться все заказы, задачи, доставки, оплаты и многое другое в него. Или я не правильно мыслю?
Просто не понятно где можно использовать mongo
CRM - конечно реляционную бд. Это даст нормализацию бд и обеспечение целостности данных на уровне БД.
MongoDB (в т. ч. другие NoSQL) - когда связанность между данными отсутствует или она несущественная. Логи - хорошоий, ИМХО, пример для хранения в NoSQL. С чатом то же можно
Почему все стараются рассматривать Mongo как альтернативу *SQL? Для обеспечения целостности и управления данными - используйте *SQL. Для быстрого доступа для отображения - Mongo. Храните и оперируете в реляционной БД, а потом выгружаете в Mongo. Имхо оптимальный вариант.
Храните и оперируете в реляционной БД, а потом выгружаете в Mongo. Имхо оптимальный вариант.
Сохранять в двух местах, но для отображение определенной заказа допустим, чтобы вывести все данные то использовать mongo? Чтобы не выводить допустим информация о заказе из связанные таблиц финансов, доставок, заказа, клиентской базы и т.д, а использовать для этого mongodb или я не так понял
hollanditkzn,
Допустим добавили вы к заказу позицию, или контактное лицо, или поменяли реквизиты -> записываете эту информацию в базу и генерируете документ заказа, который кладете в Mongo. То есть если кто то захочет просмотреть заказ или сформировать отчёт (любые операции, где нужно только чтение заказа, а не его изменение), то вы выбираете его из Mongo в виде готового документа, а не собираете информацию из дюжины таблиц БД.
sim3x, Быстрее получить сформированный документ чем собирать его по 10 разным таблицам и проводить какие то дополнительные конвертации полей и обработки.
sim3x, А на практике иногда ещё условия выборки надо задавать. В Mongo для этого даже индексы есть. И всё что я говорю - это исключительно практические подходы, которые использовались в живых проектах.
upd. Бегут, потому что все рассматривают её как альтернативу реляционной БД. Но это не так. Нужно просто уметь использовать плюсы разных технологий и компенсировать минусы. А иначе получится https://habrahabr.ru/post/231213/
Простой
