Коллекция MeteorJS против массива

Question

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

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

A:

Collection Canvases {
    Canvas {
        Array Items;
    }
    Canvas {
        Array Items;
    }
}

B:

Collection Items {
    Item {
       _id
    }
    Item {
       _id
    }
}

Collection Canvases {
    Canvas {
        Array ItemIDs;
    }
    Canvas {
        Array ItemIDs;
    }
}

Или, может быть, что-то другое?

Answer 1

Поскольку Meteor " определяет изменения на основе полей документа MongoDB. Но... не поддерживает вложенные поля и массивы ", я бы использовал некоторую структуру данных, как вы предложили в своем предложении B: две коллекции. Это гарантирует, что только новые / обновленные элементы будут отправлены клиентам, а не все элементы холста.

Затем установите связь между Холстом и Предметами, как указал Саймон в своем комментарии выше: Canvas{_id:"xxx"} Item{_id:"xxx",canvasId:"xxx"}, (Я использую аналогичный подход в моем проекте minutocash, который отлично работает.)

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