nosql модели списка желаний - Борьба между ссылкой и встроенным документом

Question

У меня возник вопрос о моделировании списков желаний с использованием mongodb и mongoose. Идея заключается в том, что мне нужно, чтобы у пользователя было много разных списков пожеланий, которые содержат много пожеланий, каждое желание ссылается на одну статью.

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

То же самое, что и желание, встроенное в список пожеланий.

Так что я получил что-то вроде этого

var UserSchema = new Schema({ 
... 
    wishlists: [wishlistSchema] 
... 
}) 

var WishlistSchema = new Schema({ 
... 
    wishes: [wishSchema] 
... 
}) 

но мой вопрос, что делать с этой статьей? следует использовать ссылку или скопировать данные статьи во встроенный документ.

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

Если я использую ссылку, обновление больше не проблема, но у меня возникла проблема, когда я фильтрую желание в зависимости от их критериев статьи (когда я фильтрую пожелания в зависимости от цены, категории и т. Д.).

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

Является ли этот запрос выполнимым?

Sry для вопроса loooong и для моего плохого английского: /, но любые советы были бы замечательными!

Answer 1

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

Я бы предпочел встраивать и обновлять несколько схем, когда есть изменение, в отличие от выполнения ref, по нескольким причинам.

1. Get будет быстро и легко, и фильтр не является проблемой (как вы сказали)
2. Получить операции обычно происходят намного чаще, чем обновления и правильной индексации, вы действительно не должны беспокоиться о производительности.
3. Он использует принцип отсутствия схемы NoSQL, и вы будете менее подвержены реструктуризации из-за изменений требований (новая сортировка, новые фильтры и т. Д.)
4. Пейджинг будет намного меньше проблем, и пользовательский интерфейс не будет ограниченный его дизайном с пейджингом и лимитом.
5. Присоединение может стать дорогостоящим. Избыточные данные могут быть затруднительными для обновления, но это всегда лучше, чем неспособность отображать данные определенным образом, потому что ваша схема нормализована и соединение затруднено.

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