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?