CODEWITHSUNDEEP
mongodbdata-modelingdatabasenosql
Bassem Reda Zohdy
Bassem Reda Zohdy

Reputation: 12942

Dynamic Data inside MongoDB

I'm making dynamic data storage, which it was in relational data base as:

form -> field
form -> form_data
field -> field_data
form_data -> filed_data

and field data contains field_id, form_data_id, and value

but for scalability and performance I'm planing to move form_data and field_data to MongoDB and my problem now is how to design MongoDB collections, using one collection for all form_data and move field_data to map inside it and key is field_id and value is the value of this field_data, or make collection for each form record and store data direct in form_data without map as the all data in this case will be consistent.

Upvotes: 0

Views: 1762

Answers (1)

Philipp
Philipp

Reputation: 69663

In document-oriented databases like MongoDB you should always favor aggregation over references, because they don't support JOIN-operations on the database to link multiple documents.

That means that a "A has many B" relationship between two entities should not be modeled as two tables A and B, but rather as one collection of A where each A has an embedded array of B objects.

In the context of MongoDB, there is however an additional limitation: MongoDB doesn't like objects which grow. When an object accumulates more and more data over its lifetime, the object will grow. That means that the hard drive space MongoDB allocated for it will run out again and again, which will require space reallocation. This takes performance and fragments the database. Also, MongoDB has an artificial size limit for documents, mainly to discourage developers from designing growing objects.

Therefor:

When the data exists at creation, embed it directly.

When more and more data is added after creation, put it into a different collection.

When a form has X fields, the number of fields will likely not change much over its lifetime. So you should embed the fields and their descriptions directly into the form object.

But the number of answers entered into these forms will grow over time, which means that these should be treated as separate objects in a separate collection.

So I would recommend you to have two collections, forms and form_data.

Each document in forms embeds a sub-object of fields with the static field properties.

Each document in form_data has a field with the _id of the corresponding form and embeds a sub-object of field_data which uses the same keys as the fields sub-object of forms and stores the entries the user made in that form.

When your use-case requires frequent access to the aggregated data (like when you want to publish the up-to-date statistics on a public website), you could also store this information in the fields of forms to avoid an expensive aggregation query over many form_data documents. MongoDB in general recommends to orient your database schema rather on your performance requirements than on the semantics of your data.

Regarding your remark "all data in this case will be consistent": keep in mind that MongoDB does not enforce referential integrity. When an application deletes or changes a document, it's the responsibility of the application to fix any outdated references to it in other documents.

Upvotes: 1

Related Questions