Schmea Design Advice for Order management and shipping

I have three collections with the following layout:

_id: ObectId
company_id: ObjectId
user_id: ObjectId
receipt_number: number
down_payment: number
comment: string
createdAt: DateTime
updatedAt: DateTime

Product {
_id: ObjectId
order_id: ObjectId
name: string
link: string
cost: number
expected_delivery_date: DateTime
current_status: Enum
createdAt: DateTime
updatedAt: DateTime

_id: ObjectId
product_id: ObjectId
order_id: ObjectId
status: Enum
details: string
createdAt: DateTime
updatedAt: DateTime

I came from a relational DB background and wanted to experiment with a NoSql database for learning. Due to this I modeled it based on relational experience however decided to revalidate the schema design after learning about the specifics of mongodb. Given that an Order can have many products, I was wondering if this should be embedded onto the Order document itself. The issue arises from the fact that a products array can potentially be unbounded. While usually it can be anywhere between 1 and 10 there is the possibility that it can scale 100+ products though i expect this to be rare.

What advice would you give to model this for scalability? Additionally the order must keep track of the number of products it has which i currently use a $lookup and $size check to fill this data when the order is pulled.

On the other hand order updates has a many-to-many with products and is most times taken separately from the order through a lazy query so I dont think it should be embedded

Finally there is a possibility that I may need to include shipping details, delivery and supplier in the future but I dont know the specifics and therefore cannot include it right now.

PS: I am rather new to modelling this way and it seems to be much more complicated than a relational db. Either that or im just overthinking it.

Hey @Awakening_Quasar,

Welcome to the MongoDB Community Forums! :leaves:

When it comes to designing schema in MongoDB, it’s important to keep in mind that the design should be optimized for the specific use cases and queries that will be performed on the data ie. things that are queried together should stay together. This means that there isn’t necessarily a “one-size-fits-all” approach to schema design and it may be beneficial to work from the required queries first and let the schema design follow the query pattern.

Can the product change after the order was created? If not, embedding is probably beneficial here.

The max document size is 16MB. I would suggest you experiment with the largest order you can think of, and check if this can exceed this limit or not. 16MB is a lot, and this doesn’t sound like a case of possible unbounded array growth. Just that some are very large. If the 16 MB limit is exceeded, then it might make sense to store the product information as a separate collection and reference the order_id in each product document.

As for potential future additions to the schema, it’s important to keep in mind that schema design is an iterative process and can evolve over time as new requirements arise. It’s okay to start with a simpler schema and add additional fields or collections as and when needed. You can also use mgeneratejs to create sample documents quickly in any number, so the design can be tested easily.

Additionally, since you’re new to MongoDB, I’m linking some more useful resources that you can explore:
Data Modelling Course
Data Model Design

Please let us know if you have any additional questions. Feel free to reach out for anything else as well.


1 Like