Does exists any Mongo design patterns to be able to make all forms and datagrids totally dynamic?

Working with Data
1

Does exists any Mongo design patterns to be able to make all forms and datagrids totally dynamic? Which approach do you prefer, store data from each (dynamically created) form to separate collection (new form will create new collection), or store data from all forms into single collection? Isn’t it slower?

I would like to:

  • generate all forms dynamically (be able to manage form fields),
  • generate dynamically sub-forms and assign into main forms,
  • ability to put into the form “inputs” or “indicators”,
  • ability to management items layout,
  • ability to create “dynamic fields” which can contains some calculation (from data of this form or data from all another forms).

Thanks a lot for any idea!

2

You’re describing an application. You can make all forms and datagrids totally dynamic - but that requires code… an application. Applications interact with the database to add, update, delete data… are you asking about an application that already does this? It sounds like you’re describing a low-code, nocode solution. I can’t recommend any of those… sorry. Good luck - I hope you find what you’re looking for.

2 Likes
3

Hello @Michael_Lynn, thank you for you answer. I will made (I already developed) application (it works without any problems, but I have a lot dilemas and some unsolved things). To make my question more clear, I’m finding and informationm if exists some standardized data model to cover my expectations.

…or how to effectively make the data model for my use case. I know modeling patterns of mongo, but in my case model and relations will be very complicated, because I would like to have high flexibility.

The main Question Nr. 1 is, example:
I will be have 20 tenants. Each tenant will create for example 20 “custom” forms in app. Is it better to store data from those tenants into single collection or is it better to split into separate collections?

If I will split it, data will be better organized (I think) and more simple aceessible and clearer like data merged into single collection. On the other hand, dynamically created collections can makes a problem with for example mongo sharding. Which way do you prefer?

Thanks a lot for an each help, experiences, recomendations or ideas.

4

There are a number of factors which will inform the decision we make about the data model for a multi-tenant application… you almost NEVER want to go with a separate collection per tenant… that gets hard to scale very quickly. Imagine if you make a change to the data model for one of the customers.

Since there are only 20 or so tenants, storing all tenant data in a single collection may work for you. The primary concern there is privacy and data isolation. Are there privacy concerns with the data? HIPPAA for example?

How much data will be stored for each tenant? This may inform the decision we make about the data model, specifically regarding sharding… with only 20 tenants, I can’t imagine you’ll have enough data to dictate sharding.

Another alternative is a database per tenant. This will offer you the data isolation you may require but comes with the downside of requiring memory and cpu for each database.

Can you tell me more about the data - how much total storage will you require. Can you tell me more about the users of the application - where will they be and what does the volume of user interactions look like?

5

Hello @Michael_Lynn, thanks a lot for your answer. Number of tenants was “only” an example. They can be hundreds of tenants.

For each tenants can be stored about (estimate) 200K mongo documents from “manual” entered into the database,

  • for each tenant will be stored also about 500K of small documents PER DAY (data acquisition data), from which will be calcullated statistics each new minutes. History of this data will be 90 days => 500K * 90 45M of documents for each tenant (for those tenants, where will be this “high load”, I will create separate instances).

“Are there privacy concerns with the data?” Yes, It can be. I’m running separate application layer for the data isolation (in same collection of all tenants), but those mechanism is not enough I think, some “stronger” isolation level I happy to welcome.

All users data (for all tenants) will be sitting in same collection. One user can be and owner of multiple tenants and can switch between them.

I’m ready to store data into the single or separate collections. Both ways I tested and they are working, but I would like to make “good” decision also to the future. I dont want after a year completely refactor whole app, If I found some problems or limitations.

…also on the other hand, of BIs like Qlik or others is better to store each form data into separate collections (it’s better for work I think).

6

@Michael_Lynn …small notice to previous message, my current point of view is:

  • store “fixed” non-modular data with fixed logic into the multiple (not dynamically created) collections same for all tenants (for example users, contacts, tasks, etc…)

  • store “modular” data into store each form into dynamically created (separate) collections for example “form_<tenant_id>_<collection_name>”
    …or
    into the single collection (90% of “manual entered” app data will be stored into this single collection)

  • store “modular” data acquisition data (millions of documents) separately from “manual entered data” to elliminate performance issues, for those data I will also need modularity (but not so complex, like for those “forms” data).

For me is more important flexibility than performance.
Also is more important long-term sustainability and transparency than performance.