Two tables have many-to-many relationships. Do you need to associate tables?

There are two table rule tables and group tables: tb_rules and tb_group. These two tables are in the auth permission. Obviously they are multi-to-many relationships. A rule can belong to multiple groups, A group can have multiple rules. In principle, there should be an association table tb_group_rules (group_id, rule_id )... there are two table rule tables and group tables: tb_rules, tb_group

This isauthThe two tables in the permission are obviously multi-to-many relationships. One rule can belong to multiple groups and one group can have multiple rules;

In principle, there should be an associated table.tb_group_rules(group_id，rule_id)

HoweverthinkPHPOfauthYou do not need to associate tables in the class.tb_groupThere isrulesField, save'1,2,3,4,5,6,7,8,9'Such a ruleid;

I guess he does not need to join tables. There may be several considerations:
1: Generally, there are not many rules in each group. It is convenient to use one field for management. It is unnecessary to create an associated table to waste resources.
2: Generally, group rules are obtained.id, Directly change the rules field during authorization

But I think it is always bad:
1: There are not many rules for general groups, but general rules. Who can say this? I am not at ease.
2: Do you want to use and separate rules? If you want to cancel a rule, this is extremely inconvenient (the program can only find out the rule fields, split them, splice them, and save them ), causing trouble for maintenance
3: it is convenient to change rules through groups. However, it is troublesome if I want to see which group the rule belongs to or authorize some groups according to the rule.

If you use an associated table, it is not a problem and is also conducive to program maintenance.

The above is my understanding and analysis of the advantages and disadvantages. If there is anything wrong, please correct me.

My questions, such as the question, when to use the joined table, and the trade-offs between the pros and cons, such as the situation in the case column.

Reply content:

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

This isauthThe two tables in the permission are obviously multi-to-many relationships. One rule can belong to multiple groups and one group can have multiple rules;

In principle, there should be an associated table.tb_group_rules(group_id，rule_id)

HoweverthinkPHPOfauthYou do not need to associate tables in the class.tb_groupThere isrulesField, save'1,2,3,4,5,6,7,8,9'Such a ruleid;

I guess he does not need to join tables. There may be several considerations:
1: Generally, there are not many rules in each group. It is convenient to use one field for management. It is unnecessary to create an associated table to waste resources.
2: Generally, group rules are obtained.id, Directly change the rules field during authorization

But I think it is always bad:
1: There are not many rules for general groups, but general rules. Who can say this? I am not at ease.
2: Do you want to use and separate rules? If you want to cancel a rule, this is extremely inconvenient (the program can only find out the rule fields, split them, splice them, and save them ), causing trouble for maintenance
3: it is convenient to change rules through groups. However, it is troublesome if I want to see which group the rule belongs to or authorize some groups according to the rule.

If you use an associated table, it is not a problem and is also conducive to program maintenance.

The above is my understanding and analysis of the advantages and disadvantages. If there is anything wrong, please correct me.

My questions, such as the question, when to use the joined table, and the trade-offs between the pros and cons, such as the situation in the case column.

I will reply to my point of view based on the three points that you think are always bad at this time (because of your problems, I will make a public comment ).
1. Generally, you guess the general situation, and you deny the general situation, so this is your own problem.
2. Split. If the rules field is currently stored as '1, 2, 3, 4, 5, 6, 7, 8, 9 ', When you delete the role 2 on the management interface, instead of dividing the existing stored rules Field Values, remove 2 and combine them. Instead, click "save" on the management interface. The form submits the role information of the Group for combination and merging. Then, update and save the rules field information. This is not the case you described: "split, extract, splice, and save", which does bring trouble to maintenance, but the actual practice should not be described like this.
3. "But if I want to see which group it belongs to according to the rules," thinkPHP did not directly consider this when designing it.