(db.createView())? Спринг дата, монго драйвер 3.8 (мб mongotemplate умеет) И если да, то как правильно это делать?
Если более развернуто - а вообще норм идея реализовать софт делит через вьюху, в которой записи ток с deleted:false (чтобы не кастомизироаать запросы - спрингдата даёт из коробки)?
Индексы там от родной коллекции судя по доке.
Или же это плохая идея? (And why)
2) тоже спринг дата и монго. Есть set<optionsDocument> в документе userDocument.
Если вешать (юзать) @DBRef до поры до времени все ок, пока не захочется сделать аггрегацию по содержимому optionsDocument... Да и умные люди пишут что надо юзать мануал референс (т.к. есть рестрикшнв по дбреф)?
Как это реализовывать? Делать set<objectId> и все методы спринг даты (find/findall)вручную переписывать на аггрегации? Или можно просто тоже аноташку навесить?
А норм будет оставить set<optionsDocument> и хранить там сразу все данные (ембед реф это называется вроде или как..) ПЛЮС в отдельной коллекции ТОЖЕ хранить optionsDocument (в примерах доки такой вариант не рассматривался) и если optionsDocument изменится - у всех юзеров его тоже менять (1 option это по сути список прав с именем, который может меняться, я полагаю меняться будет редко, добавляться чаще, но последнее нас не аффектит), а при создании/изменении юзера чекать по айди все ли поля совпадают с option в юзере и в своей коллекции (поля у опшн всего два-имя и список прав).
Сори если несу дичь парни, но от помощи не откажусь :3
1) зависит от того, насколько эффективен индекс по deleted. В остальном почему бы и нет 2) не совсем понятно. Если без спринга, какая у вас схема в итоге? В документе пользователя есть массив документов с опциями?
Обсуждают сегодня