topic description
the above problem can not be avoided is that there are two copies of the data, such as an article being edited in the background and an article that the user is browsing. How to achieve the amount of data modification, the data takes up the least amount of space. If you look at the article alone, such as the article table, it is easier to deal with the problem and back up the data. For example, when you need to edit an article, set up a backup data for the article, and the backup data is modified in the background, so that it does not affect the browsing of the foreground users. When the background is modified, click publish, and the backup data overwrites the original data, while deleting the backup data, which is a bit like the bak file in Linux. This is the case with additions, deletions and modifications. Of course, this idea can also be used in reverse, creating a quick backup data, directly modifying the original data in the background, and users browsing the backup data. In this way, the logic of user browsing needs to be dealt with specially. Here is a single table, this way of thinking can be solved. But if it is multi-table data, such as articles have categories, entertainment articles, news articles, etc., how to deal with data linkage when editing article categories. A little more articles have one or more tags, such as piece articles and lace articles. Three meters linkage, all need to maintain the change state. In this case, the way you just added backup data over there will be extremely complicated. I don"t know if the great gods in the jar have any good ideas.
sources of topics and their own ideas
here, we have done a two-table linkage data before, and there are two roles that are somewhat similar to articles and tags. An article has one or more tags. The landlord designed three tables, article tables and label tables. The article <-> tag relation table is linked by the tag and the article <-> tag relation table. when adding, deleting or changing the tag, the relationship table is linked at the same time, and the background modification is completed and released uniformly.
the owner backs up both the tag and the relational table. When the tag is modified, the tag backup data is added and linked at the same time. The tag data in the relational table will be backed up anyway. When deleting, it is the same as modifying. Add the simplest, only need to add label backup, there is no data processing in the relational table. The middle involves the addition and deletion of the original data and the deletion and modification of the backup data. I have done a lot of work, and I deeply feel that I have been fooled by the plan I designed.
there are other ideas, too.
for example, the landlord has thought about designing double fields when designing a table, just like a thing from both positive and negative sides, the positive side is for others to see, and the negative side is for others to see. In that case, there is only one piece of data, an id, in the data table. It"s easy to maintain, and the flaw is field redundancy.
there are also extremely violent practices, two similar tables, which are somewhat similar to the idea of the above method and are equally redundant.