Would like to ask and exchange the strategy of database table design, I hope you can give me some advice?

I am currently working on the design of a database table for a data management system, but I have encountered such a situation:

for example, there are two types of data, one is grouping group, the other is member member;
, and then each group has a lot of other information (such as belonging place, category, etc.), and each member has a lot of other information (such as name, gender, etc.).
group and member are many-to-many, that is, a group can have multiple member and a member can correspond to multiple group.

so my current idea is to design three tables:

  • group information table, primary key groupId
  • member information table, primary key memberId
  • linked table with two fields, groupId and memberId, to store the correspondence.

but in fact, in addition to member,group, there is also a many-to-many relationship with event event, and other information, in short, all kinds of many-to-many.

so the result is a lot of linked tables with two fields (not counting the self-incrementing id of the table), so there are so many tables that it"s a bit cumbersome to maintain.

and in that case, you always need to set up on delete cascade and so on, which is a bit troublesome.

I don"t know if what I"m doing is the right way, and it"s a little scary without database professionals to help me design so many tables.
and is there a slightly clearer way to do this? And are there any hidden dangers?


my suggestion is
1. Remove on delete cascade, user association deletion, because using on delete cascade will consume database resources
2. If you think there are a lot of watches, how many are they? Whether it can be marked in the form of ER diagram or not, whether it is DBA or other developers, they all have a clear idea of
3. Is it true that there are so many many-to-many relationships? In fact, some needs should be unwarranted. I suggest review to see if there are really so many-to-many relationships.
for example, just for example:
from a company level, there will be no one person in two departments
then there is no need to consider many-to-many situations in table design, just one-to-one.


1. The table primary key is id
2. Do not use cascade operation, use program to control, do soft delete

Menu