Currently, pid is used in the User table to associate the upper and lower-level relationship. When counting the total number of lower-level relations of a user, recursive queries are used to grade 19, however, the website will be dragged to death when the number of subusers is large. What should I do? Thank you .. Currently, pid is used in the User table to associate the upper and lower-level relationship. When counting the total number of lower-level relations of a user, recursive queries are used to grade 19, however, the website will be dragged to death when the number of subusers is large. What should I do? Thank you ..
Reply content:
Currently, pid is used in the User table to associate the upper and lower-level relationship. When counting the total number of lower-level relations of a user, recursive queries are used to grade 19, however, the website will be dragged to death when the number of subusers is large. What should I do? Thank you ..
Add a path field
In fact, in many e-commerce sites, this kind of problem similar to the unlimited classification is also encountered. We sometimes add a pid to mark the subclass, at the end of the query, you have to destroy yourself.
At this time, we can modify the database table structure.Data redundancyThis problem is solved.
Supplement:
You can add a column named pid_list in the current table. The storage format is 1, 2, 3 1 is the highest level, 2 is online, and 3 is your own id.
You can also add a level of Depth that identifies your own, level 1 is 1, corresponding to the number level of pid_list.
After adding this, it is much easier for us to query again.
Reference stepless Classification
You can add a path field.
Add A total number of children directly to each user record. A-> B-> C-> D. If C invites D, update ABC three to add 1. This task can be processed asynchronously if it is not real-time.