the problem is complicated, so make the description as simple as possible
for example, a data table that stores articles is stored in mongodb
1. There are uncertain columns, such as click rate, content, title, reply, and the number of user uid, benefits, which may be more than a dozen or hundreds. It may increase or decrease, and it is dynamic.
2, the number of storage per column is uncertain, such as replying to this field, there may be millions, or there may be only one.
3. Each field needs to be able to store the version. For example, in the content field, there may be multiple versions, version 1, version 2, and version 3. The number of versions is uncertain.
this is how I designed it
1. Data sheet: data. Store the basic information of the article. For example, the adding time of the article, the release status of the article and so on.
2. Field table: field. Store specific field content, such as reply, content, title.
3. There is also a data table: version. Store the version. The details of each version are still stored in field
current problem:
1. Storage is fine. For example, I can query the reply and content of an article.
2. There is a performance problem. For example, paging, listing 25 items on a page. Each item needs to list some data to the user in the list. Such as title, content, time and so on. About 7 fields. It adds up to 257,174 queries, which took about 10 seconds.
if you solve this problem, you may need to write a copy of this data to the data table in advance. That is, anti-paradigm. For example:
field:{
title:"",
content:"",
}store such redundant data in the data table.
3, the problem of search. It seems that there are still some functional limitations and performance problems.
at present, on the whole, I feel that the design is very complex, the code is very tired, and the problems emerge one after another.
I don"t know whether there is a database design problem or that mongodb is not suitable for storing such data.
if it were you, how would you design this database