Data modeling for my application

[Tech_General]

Hi everyone!

First time visiting, glad to be part of this community.

I’m developing an inventory service and I have the following entities:

Business Inventory.

User inventory

Company Inventory ( can be multiple depending on region/country )

Basically, the products are containers (categorized by type: S/M/L).

Not having a unique identifier for each container.

As a result, inventory is saved at the quantity level.

For example : container type : S , quantity : 5000

Business inventory is managed by the company, so when it runs out, we will add more from the same type.

UserInventory on the other hand , is maintained for the period that the user rents the container ( no purchases in the app , only rentals )

So for example, if a user is now renting a container from a specific business,

we need to decrease the quantity from the rented types in the business inventory, and add those to the UserInventory.

The same applies for filling stock for the business .

The opposite is true when returning rented containers.

Each container within the same “order” can have a different return time.

Container can have different status at the UserInventory level ( active / charged )

[charged if the user is late for the rental period]

And different statuses on Business Inventory level ( active/ dirty … )

And different statuses on the Opa inventory.

My questions are:

1.Is it better to maintain a single document for user per container type ( so 3 types, 3 documents per user) and the same for business ? Each container type has one document that holds all the user rents, business holdings, and company holdings.

2. did the inventory documents need to be on the collection ( otherwise , how can I make sure that both add/subtract from both inventories are occurring)

3. In regards to question 1, I feel like there is a chance of losing data. This is because multiple users will try to update the same business inventory document. This is because decrease / increase the stock will override other operations.

[Satyam (Satyam Gupta)]

Hey @Tech_General,

Welcome to the MongoDB Community Forums!

Maintaining a single document per user is a good idea if the number of users and inventory is less. This could simplify queries and updates, as you wouldn’t need to filter through multiple documents to find a specific container type. However, it could also lead to documents becoming large with time. Another approach is maintaining separate collections for the three inventory types. In business inventory, you can maintain a reference of all the users that have currently rented out that particular inventory.

There are advantages and disadvantages to both approaches. Which one is best would depend on your use case, your most frequent queries and updates, and your expected workload. Please also note that MongoDB has a document size limit of 16MB, so you would need to find a balance so no document can grow indefinitely.

But this being said, a general rule of thumb while modeling data in MongoDB is that things that are queried together should stay together. Thus, it may be beneficial to work from the required queries first, making it as simple as possible, and let the schema design follow the query pattern.
I would suggest you to experiment with multiple schema design ideas. You can use mgeneratejs to create sample documents quickly in any number, so the design can be tested easily.

Additionally, I am also attaching posts from our MongoDB blog series that might be useful to you:
Retail Architecture Best Practices
Inventory Management with MongoDB Atlas

@Tech_General

I feel like there is a chance of losing data. This is because multiple users will try to update the same business inventory document. This is because decrease / increase the stock will override other operations.

In MongoDB, all operations are ACID compliant which means all database transactions are processed in a reliable way, resulting in correctness. For situations that require atomicity of reads and writes to multiple documents (in single or multiple collections), MongoDB supports multi-document transactions. With distributed transactions, transactions can be used across multiple operations, collections, databases, documents, and shards. You can read more about this from the documentation:
Transactions
Concurrency FAQs in MongoDB

Please feel free to reach out for anything else as well.

Regards,
Satyam