- With one set or divided into two sets?
- If a collection is used, what will be done with the different types of data contained in the collection and branch?
- If it is divided into two sets, how can I query if I want to display the details of revenue and expenditure?
- If a collection is used, then each document needs a field to identify whether the document type is revenue detail or support detail.
- If two collections are used, when displaying the income and expenditure details, you need to query the income collection and the expenditure collection respectively through two queries, and then display them together.
According to your problem is not very specific needs, and then detailed analysis:
- For a collection, each revenue and expenditure record is a document put into the collection. As for different types of data, document is free schema and there is no problem in data storage. What you are struggling with is how to deal with and display different types of data of revenue and expenditure, which requires you to well define the data structure and field composition of revenue and expenditure details. For queries, a collection is very easy. It can be queried according to time, and then processed and displayed in the results according to the fields that identify revenue and expenditure types.
- For the case of dividing into two collections, it is not a problem at all for the data with different types of income and expenditure, because you store them separately. At this time, the collection is basically two different table in the relational db, each storing its own data and not interfering with each other. For queries, it is more troublesome. Generally speaking, the income details and expenditure details need to be extracted twice from mongodb according to time, and then the two are merged and sorted according to time sequence. At this time, the sorting workload is transferred from mongodb to the application end.
Each of the two schemes has its own advantages and disadvantages. If your data volume is not very large, it is recommended to adopt the first scheme, one collection for storage and easy access. If the amount of data is very large, the second scheme can be adopted to transfer the pressure to the application end. After all, the application expansion is more convenient than the database expansion.
Personal opinions suggest that the first scheme should be adopted and stored in a collection, which has no pressure on the small amount of data. If there is a large amount of data, the revenue and expenditure details of different time periods can be stored in multiple collection according to time, and displayed according to time periods when displayed at the front end. In this way, as time goes by, only the collection needs to be increased horizontally, and the code of data access does not need to be changed. When querying, it is only necessary to simply switch different collections according to the query time period, which is simple and efficient.