I’ve just started using Meteor, and I have a philosophical question that I want to ask before I disappear down a rabbit hole that I then struggle to extricate myself from.
For my app, I have a projects collection, and each project document in the collection needs to have some (let’s say) ‘profit’ and ‘costs’ documents that can be inserted and associated with it.
I assumed that the best ‘no sql’ way of doing this would be to have the ‘profits’ and ‘costs’ each as a subdocument in an array on the project document itself. I have done this once before with Mongo.
Now that I have been reading around about it on Stackoverflow etc, I’m not so sure. I will need to perform calculations using the fields from those sub-documents, and I’d like to figure out now whether I’m doing the right thing before I proceed.
For example, it seems surprisingly difficult to return and manipulate an array of subdocuments in meteor, and I’ve already had to manually affix ids for the subdocuments because it doesn’t come as standard.
I want the app to be as reactive as possible, so am I really better off having a separate collection for ‘profits’ and ‘costs’ and just return them by having them tagged with the project id, rather than having them as sub-documents of the main project document? This is counter-intuitive to me, if you have thousands of documents, but mongo and meteor seem to be trying to quietly but insistently communicate to me that I’ll regret it if I don’t do it this way.
Any help anybody can offer me on this would be appreciated, thanks.