MongoDB - Дизайн базы данных с родителями и детьми

Question

В моем приложении у меня есть Пользователи таблица в БД и их Сообщения на форуме.

В каждом сообщении есть ссылка на профиль пользователя, который его написал. .

Теперь, если я удаляю пользователя из БД - я хочу, чтобы его сообщения оставались, но с атрибутом «этот пользователь (автор) был удален».

Как мне лечить в этом случае? Пользователь может оставить несколько тысяч сообщений, поэтому, если я хочу удалить пользователя, мне нужно выбрать все его сообщения и обновить их по одному? Это может занять много времени.

Если я отмечу пользователя как «отключенного» (и фактически не удаляю его), тогда клиенту потребуется отправлять множество дополнительных запросов для каждого предоставленного сообщения - это даже хуже.

Так как мне обращаться с дочерними объектами, если я удаляю родительский объект?

Что вы думаете? Может быть, есть лучший подход?

Answer 1

Вы не можете хранить информацию о пользователях и сообщения вместе в одном документе в коллекции, так как вы будете извлекать информацию о пользователях и сообщения отдельно для разных целей, а также добавлять большое количество сообщений в документ пользователя не представляется возможным. Итак, что вы сделали, имея две разные коллекции Пользователи & Запись является правильной & В Записи коллекция поддерживает одно ключевое поле, которое относится к Пользователь (уникальный userid или _id пользовательского документа) также правильно выполнен.

Вы можете избежать сохранения Пользователь отношений в Сообщений и сохранять все идентификаторы сообщений в коллекции пользователей, только если количество сообщений меньше, а также это работает не во всех ваших случаях. Сказать, что проектирование базы данных действительно зависит от ваших операций с БД.

Мне нужно выбрать все его сообщения и обновить их по одному?

Нет, вы не понимаете? нужно выбирать и удалять по одному, после успешного удаления / отключения пользователя вы будете запускать один запрос для сообщений , используя .updateMany () с фильтром (userId или _id), чтобы найти все документы, относящиеся к конкретному пользователю и добавить новое поле с именем isUserDeletedOrDisabled : true, поэтому, когда бы вы ни извлекали посты для различных страниц вашего приложения, вы избегали бы извлечения тех постов, которые имеют флаг isUserDeletedOrDisabled и его true, обычно при вставке новых сообщений документов - этот флаг вам не нужен. После Пользователь обновлений вы добавите это поле с true и сделаете его false, как только пользователь вернется ..

например Пн go БД, где присоединяется 2 Таблицы - дорогая операция?

Я не думаю, что объединение двух коллекций с использованием $ lookup стоит очень дорого, все зависит от размера набора данных / индекса / конфигурации MongoDB. Иметь индексы для полей ключей (например, в сообщениях в коллекции пользователя связанных полей плюс isUserDeletedOrDisabled ). Таким образом, для большинства приложений, если они будут работать нормально с правильными конфигами на месте.

Агрегирование может помочь вам с легкостью удовлетворить большинство повседневных потребностей, кроме того, вы можете проверить производительность запросов и улучшить их. это можно посмотреть в executeStats, предоставленном .explain () (или) $ объяснение . Подробнее читайте: Оптимизация запросов