MeteorJS collection vs. array

Question

I am creating an application using MeteorJS that allows users to create items (e.g, text, images) and to collaboratively spatially organize these on a canvas. Multiple canvases can be created. In the future, items may be reused in or copied between (I am unsure yet) multiple canvases. I have never designed a collaborative (or even database driven) application before.

I could not find the possibility to create nested MeteorJS collections, and I am unsure about the (dis)advantages (e.g. considering scalability, speed) of using multiple collections vs. using an array of objects inside a collection, so I wonder what a good design pattern would be:

A:

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

B:

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

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

Or perhaps something different?

I'd use two collections, one for Canvas, one for Items. I'd store the parent canvas id in the Items collection, this way you can easily find all items in a particular canvas, and also reparent an item to another canvas. Canvas{_id:"xxx"} Item{_id:"xxx",canvasId:"xxx"} — saimeunt, Dec 28 '13 at 14:35

score 1 · Accepted Answer · edited May 23 '17 at 12:13

Since Meteor "identifies changes based on the fields of the MongoDB document. But ... does not support nested fields and arrays", I'd use some data structure like you suggested in your proposal B: two collections. This ensures that only new/ updated items get pushed out to clients and not all items of a canvas.

Then make the relation between Canvas and Items as saimeunt pointed out in his comment above: Canvas{_id:"xxx"} Item{_id:"xxx",canvasId:"xxx"}. (I'm using a similar approach in my project minutocash which works fine.)

Furthermore, you can publish all related items of a canvas with the publish-with-relations package as David Weldon pointed out in this answer to a question of mine, about an issue which you might run into later with this data structure.

All of this looks correct. I generally prefer to keep my meteor collections relational even though that's not the recommended way to use mongodb. It does force you to use something like PWR, but that doesn't seem to be a big deal given the new oplog tailing in 0.7. If you can't get access to the oplog though, reactive joins can get expensive (CPU) - so be warned. — David Weldon, Dec 28 '13 at 20:32

MeteorJS collection vs. array

1 Answers1