If you use a collection, then each document needs to have a field to identify whether the document type is an income detail or a support detail;
If you use two collections, when displaying the income and expenditure details, you need to query the income collection and expenditure collection separately through two queries, and then merge them for display;
Let’s analyze the non-specific requirements in your question in detail:
For a collection, each revenue and expenditure record is a document placed in the collection. As for different types of data, the document is a free schema, and there is no problem in data storage. What you are struggling with is just different types of revenue and expenditure. How to process and display the data requires you to well define the data structure and field composition of the income and expenditure details. For querying, a collection is very easy. You can query based on time, and then display the results separately according to the field that identifies the income and expenditure type;
If you divide it into two collections, it is not a problem to store different types of data, because you store them separately. At this time, the collection is basically two different tables in the relational db, each containing its own data without interfering with each other; for queries It is more troublesome. Generally speaking, you need to pull out the income details and expenditure details from mongodb in two times according to time, and then merge and sort the two in chronological order. At this time, the sorting workload is transferred from mongodb to the application. end.
Both options have their own pros and cons. If the amount of data you have is not very large, it is recommended to use the first option, which is stored in a collection and is easy to access. If the amount of data is large, you can adopt the second option to reduce the pressure. Transfer it to the application side. After all, application expansion is more convenient than database expansion.
Personal opinion suggests using the first solution, which is stored in a collection. If the amount of data is not large, there is no pressure. If the amount of data is large, the income and expenditure details of different time periods can be stored in multiple collections according to time. When displayed on the front end, display according to time period. In this case, as time goes by, you only need to increase the collection horizontally, and the data access code does not need to be changed. When querying, you only need to simply switch different collections according to the query time period, which is simple and efficient.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Intuitive idea:
Let’s analyze the non-specific requirements in your question in detail:
Both options have their own pros and cons. If the amount of data you have is not very large, it is recommended to use the first option, which is stored in a collection and is easy to access. If the amount of data is large, you can adopt the second option to reduce the pressure. Transfer it to the application side. After all, application expansion is more convenient than database expansion.
Personal opinion suggests using the first solution, which is stored in a collection. If the amount of data is not large, there is no pressure. If the amount of data is large, the income and expenditure details of different time periods can be stored in multiple collections according to time. When displayed on the front end, display according to time period. In this case, as time goes by, you only need to increase the collection horizontally, and the data access code does not need to be changed. When querying, you only need to simply switch different collections according to the query time period, which is simple and efficient.