2012-03-03 6 views
2

У меня есть коллекция Parent s, которые содержат EmbeddedThing s, и каждый EmbeddedThing содержит ссылку на созданный ею User.mongodb: Это где я должен просто нормализовать свои внедренные объекты?

UserCollection: [ 
    { 
    _id: ObjectId(…), 
    name: '…' 
    }, 
    … 
] 

ParentCollection: [ 
    { 
    _id: ObjectId(…), 
     EmbeddedThings: [ 
     { 
     _id: 1, 
     userId: ObjectId(…) 
     }, 
     { 
     _id: 2, 
     userId: ObjectId(…) 
     } 
    ] 
    }, 
    … 
] 

вскоре я понял, что мне нужно, чтобы получить все EmbeddedThing с для данного пользователя, который мне удалось достичь с помощью карты/уменьшить:

"results": [ 
    { 
    "_id": 1, 
    "value": [ `EmbeddedThing`, `EmbeddedThing`, … ] 
    }, 
    { 
    "_id": 2, 
    "value": [ `EmbeddedThing`, `EmbeddedThing`, … ] 
    }, 
    … 
] 

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

Если это помогает, это для пользователей, чтобы увидеть их список EmbeddedThing s по всем Parent s, в отличие от какой-либо задачи отчетности/агрегации (что заставило меня понять, что я могу сделать это неправильно).

Спасибо!

ответ

2

«Для того, чтобы вставлять или не вставлять: это вопрос» :)

Мои правила:

  • встраивать, если внедренный объект имеет смысл только в контексте родительских объектов. Например, OrderItem без Order не имеет смысла.
  • вставлять, если это обусловлено требованиями к производительности. Очень дешево читать полное дерево документов (в отличие от необходимости делать несколько запросов и присоединяться к ним программно).

Вы должны посмотреть на свои шаблоны доступа. Если вы загружаете ParentThing несколько тысяч раз в секунду и загружаете User один раз в неделю, то карта-сокращение, вероятно, является хорошим выбором. Пользовательский запрос будет медленным, но это может быть нормально для вашего приложения.

Еще один подход - денормализовать еще больше. То есть, когда вы добавляете встроенную вещь, добавьте ее как к родительской вещи, так и к пользователю.

  • Плюсы: запросы бывают быстрыми.
  • Против: Сложный код. Двойное количество записей. Потенциальная потеря синхронизации (вы обновляете/удаляете в одном месте, но забываете делать в другом).
+0

Я люблю mongodb за его гибкость, но на самом деле ненавижу часть «это зависит», так как я должен думать о дополнительных материалах :) Поскольку это совершенно новый проект, я могу только угадать шаблон доступа. Кроме того, потому что он новый, я сосредоточен на простоте разработки, а не на скорости. Похоже, я должен просто держаться подальше от денормализации его в тот момент! – thatmarvin

+0

@thatmarvin: Мышление хорошо для вас :) –

Смежные вопросы