Hello,
In real world we have 2 entities:
- Packages - individual products that among other things contain package recipient details, category and pricing information
- Shipments - a sort of container assigned to each client and containing that client’s packages queued for shipping under that shipment ID. There is no limit to how many packages a shipment can hold, however, statistically it ranges 200 - 400/ shipment.
Since both of these are often needed to be read/ updated individually, they are stored into MongoDB as 2 separate collections like so:
Key structural points emerge:
- When a package is inserted into the system it is assigned to a shipment and it knows what shipment it belongs to.
- A shipment does not know its packages individually, however it has a precise real time information of how many of any given package (given weight and category) it has, the prices and the total amounts. So when a package is inserted, the shipment document summary is updated to reflect this.
Considering this information, I have the following questions:
- Would you say this structure is optimal, or would you have suggestions on how to improve it?
- What would be the best way to update the “Summary” document after the package is created? I can think of 2 possibilities:
a) Run an update query where package category and weight are the filters and increment numeric values.
b) Run an aggregation query on the shipment’s packages and store the result inside the shipment document. - Are transactions unavoidable if a package needs to be moved from shipment A to shipment B?
- Considering transactions, would they pose a performance problem for mass update operations? A scenario would be parsing a CSV file with 1000 packages and updating their respective shipments. It should be noted that individual transactions would not be heavy (consisting of 2-4 queries per), but having 1000 packages in a file would mean that there would be 1000 transactions run one by one.
Thank you