I’ve been reading a bit about document design for MongoDB, specifically relating to referencing, embedding and linking.
I’m still not sure what the best layout would be for the kind of documents I wish to store.
Imagine if you will, a type of dynamic form building application. Each form will have a set of static attributes (name, description, etc), a set of dynamically created fields (name = text, age = number, etc), and a set of submitted results.
Something like this:
$obj = array(
'name' => 'Test',
'description' => 'Hello',
'live' => false,
'meta' => array (
'name' => 'text',
'age' => 'number',
'sex' => 'boolean',
),
'records' => array(
array('name' => 'Test', 'age' => 20, 'sex' => true),
...
...
)
);
My confusion mainly comes from whether I should be embedding the records within the collection, or if I should create individual collections for each form. My intuition is to do the latter, while the MongoDB books I have been reading state that embedding data is ok.
Can someone please assist, given that I expect forms to have large quantities of submitted data.
Thanks.
Edit:
I also found this question to be helpful.
I would store all the form definitions in one collection, and the form submissions in another collection. You need to realize that one document (including embedded documents) can only be 16 MB right now.
It makes a lot more sense to have the submissions in a separate collection. Whether you want to have a different collection for each of your form types that is up to you. It depends a bit on how much each form will be alike, and how many different types you’re going to get.
You will not have to be afraid that MongoDB will create a non-contiguous data on disk as Mongo stores each document separately, and doesn’t care which fields are part of the document.