MongoDB Document DB Design Decision

108 views Asked by At

Getting started with document DBs, I have a question about a design decision. I'll be inserting data that contains financial transactions for many days. Not sure if I should make each transaction a doc, or make one doc for all of the data, which would cover many days.

The primary use of the application is to analyze the data in many ways, including a particular day, and day ranges.

What considerations are there in making this decision?

2

There are 2 answers

0
Dave On

It seems that if you are looking to report and analyse data based on the individual transactions (ie cut by product_id, value, buyer, date and so forth) then ideally that will be the document type, allowing indexing as required. If you make a single doc type that is just a list of transactions, I think mongo will struggle to help you much with your indexing.

0
woemler On

The design of your database should reflect the functionality your software layer is going to perform. MongoDB should have to do as little work as possible to return results to your application, so modeling your data in a way that requires as little reshaping as possible when running queries would be ideal. This can be tricky when you want to approach your data from many different angles. In my experience, even with the most general-purpose data sets, there are always fields that are queried more frequently than others. For financial data, I would guess this would either be a range of time or a person/organization. These are the fields you wither want to group your data by and/or index. For a truly general-purpose data model, I would probably just create a single document per transaction, index the transaction date descending (so more recent transactions are returned quicker), and then index all of the key fields as specifically as possible.