Two tables are many-to-many relationships, do you need an association table?

There are two table rule tables and group tables: tb_rules， tb_group

This is the auth permissions of the two tables, obviously they are many-to-many relationships, a rule can belong to more than one group, a group can have more than one rule;

According to reason, there should be an association table.tb_group_rules(group_id，rule_id)

But thinkPHP the auth class inside does not have the correlation table, is such the tb_group inside has a rules field, preserves '1,2,3,4,5,6,7,8,9' such rule id ;

I guess he doesn't have to use a related table. There are several possible considerations:
1: General rules of each group are not many, with a field management convenience, do not have to build an association table resulting in a waste of resources
2: Generally are rules that get group rules id , authorization when directly change the rule field

But I don't think it's always a good time:
1: What is called the general group of rules not much, what is called general, this who said the quasi, anyway I just don't trust
2: The rule, split good, if you want to cancel a certain rule, this is extremely inconvenient (the program can only find the rules of the field, split and then take out, in splicing, in the preservation), to maintain trouble
3: It is convenient to change rules by group, but it is more troublesome if I want to follow rules to see if it belongs to those groups, or to authorize certain groups according to the rules.

If you use an association table, it's not a problem, it's also good for program maintenance.

Above is my understanding and pros and cons of the analysis, if there is no big god please correct me

The question I'm discussing, title, is when to use the correlation table, and the tradeoffs of pros and cons, like the case in this case.

Reply content:

There are two table rule tables and group tables: tb_rules ,tb_group

This is the auth permissions of the two tables, obviously they are many-to-many relationships, a rule can belong to more than one group, a group can have more than one rule;

According to reason, there should be an association table.tb_group_rules(group_id，rule_id)

But thinkPHP the auth class inside does not have the correlation table, is such the tb_group inside has a rules field, preserves '1,2,3,4,5,6,7,8,9' such rule id ;

I guess he doesn't have to use a related table. There are several possible considerations:
1: General rules of each group are not many, with a field management convenience, do not have to build an association table resulting in a waste of resources
2: Generally are rules that get group rules id , authorization when directly change the rule field

But I don't think it's always a good time:
1: What is called the general group of rules not much, what is called general, this who said the quasi, anyway I just don't trust
2: The rule, split good, if you want to cancel a certain rule, this is extremely inconvenient (the program can only find the rules of the field, split and then take out, in splicing, in the preservation), to maintain trouble
3: It is convenient to change rules by group, but it is more troublesome if I want to follow rules to see if it belongs to those groups, or to authorize certain groups according to the rules.

If you use an association table, it's not a problem, it's also good for program maintenance.

Above is my understanding and pros and cons of the analysis, if there is no big god please correct me

The question I'm discussing, title, is when to use the correlation table, and the tradeoffs of pros and cons, like the case in this case.

Corresponding to the three points that you feel is not good at this time, I have to respond to personal views, (because of your problem, the public said that the public is right to say that po).
1, general, you guess the general situation, but you yourself deny the general situation, then this is your own problem.
2, split, if the rules field is now stored ' 1,2,3,4,5,6,7,8,9 ', then in the management interface to delete the 2nd role, not to the existing storage rules field values are split, excluding 2, in combination. Instead, after the admin interface is deleted, click Save, the form resubmit group has the role information to be combined, then update to save the Rules field information. It's not what you're describing: "Splitting and removing, splicing, saving," which does give maintenance trouble, but the practice should not be described in this way.
3, "But if I want to see the rules according to the group," This should be your business needs, thinkphp in the design of the time did not directly consider this.

