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

Всё началось с твоего совета который противоречит устоявшейся практике, рекомендациям авторов монги, и несёт в себе потенциальную проблему
Подход "нормально делай - нормально будет" это хорошо, но непонятно почему надо выбирать пусть с проблемами, а не путь без проблем. Чтобы потом их героически решать?
Если всё "делать по уму", то и тесты писать не надо. Да и тестовое окружение не нужно: можно сразу писать код без багов 🙂

А в данном случае как раз рсубд гарантирует отсутствие проблемы, т.е. именно спасёт даже если руки растут из того места

Вот совет я как раз давал исходя из личного опыта с этой базой, как раз совет в документации по поводу вложенности - вредный и несет в себе проблемы, могу привести аргументы и несколько примеров, если интересно, сам когда-то изначально по этому совету сделал вложенность, а потом переписал, ибо ну его нафиг с таким работать, получается месиво из данных, которые еще и фиг проиндексируешь нормально, а если пойдет 3-й уровень вложенности? а 4-й? это уже над каждой выборкой нужно будет "потеть" пол дня, чтобы составить запрос

Приводи
И ещё хорошо будет если расскажешь как именно ты предлагаешь гарантировать целостность данных (желательно без варианта "делать по уму") чтобы избежать очевидной проблемы битых ссылок

Достаточно просто не удалять данные, а помечать как удалённые, чтобы во всяких списках их не было

Вот и вся целостность

Каша с вложенностью, возьмем товар, у него есть бренд, у него есть категория (возможно даже 2 или 3), как на вложеных данных построить нормальную структуру? никак товар прийдется дублировать, категории прийдется дублировать и т.д. как контролировать остатки товара в этом случае? Как по нормальному переназвать категорию (прийдется апдейтить все доки)? как проиндексировать товары? как выдать при необходимости отдельно бренды и категории? как выдать товары из одной категории разных брендов? А фильтры то как строить, это вообще закачаешься, там такие запросы нужно будет строить, что самый лютый брейнфак код покажется родным русским. А еще ограничение 16мб на документ. Конечно если думать что в монге данные нужно хранить именно так то реляционки это прям манна небесная. Поэтому вложености нужно избегать.

Целостность данных контролировать на уровне приложения, если инсертим 2 дока в разные коллекции, делать это через транзакции, они гарантируют что выполнятся или все операции, или не выполнится не одной, тоже самое и с удалением и апдейтом. Ну и конечно не допускать варианта, когда пользователь своими действиями может эту целостность нарушить, вот и все.

Все, я устал, надоели

Завтра продолжим?)

не, ну нафиг, эти извечные споры чей Х длиннее, я лучше молча в сторонке за этими холиварами понаблюдаю)

так а чей же вконце концов длиннее? на чем порешали?

Не выпендривайся и бери postgresql

мой

Недостаточно, потому что ссылка на логически удалённый документ не сильно лучше ссылки на удалённый

Ты пришёл к выводу, что реляционная модель тебе подходит больше, чем нереляционная. Поздравляю!
Осталось только понять что же заставляет людей использовать для этой цели монгу, а не подходящий инструмент

Даааа? Ну-ну. Расскажи это бухгалтерам

Номенклатуры в справочнике уже нет, а документы о её продаже есть к примеру

"На уровне приложения" это всегда означает возможность ошибки. Как программной, так и административной
Добавил новую коллекцию, где есть бренды, но забыл добавить её в одну из уже написанных транзакций - это совсем не сложно
Не допускать пользователя к управлению - это вообще может прямо противоречить тз, где прописано, что администратор имеет возможность редактировать список брендов
Вариантов попортить данные масса, мне лень новые примеры приводить

Ну так это хороший кейс того, что нужны даже неактуальные данные. Который (кейс) не меняет того, что могут быть другие кейсы, где ссылка на неактуальную запись принципиально не лучше ссылки на удалённую запись. Условно - дом снесли, а Вася остался зарегистрирован в нём