想询问和交流一下数据库表设计的策略，希望大家指点一下？

Question

目前在做一个数据管理系统的数据库表设计，但是遇到了这样一个情况：比如说有两类数据，一类是分组 group，一类是成员 member；然后每一个 group 还有很多其他信息（比如归属地、类别等等），每一个 member 还有很多其他信息（比如姓名、性别等等）。group 和 member 是多对多的，也就是说，一个 group 可以有多个 member、一个 member 可以对应多个 group。所以我目前的想法是设计成三个表：group 信息表，主键 groupIdmember 信息表，主键 memberId链接表，有 groupId 和 memberId 两个字段，用于存储对应关系。但是实际上，除了 member，group 还会和事件 event 也是多对多的关系、还有等等其他的信息，总之各种多对多。所以这样造成的结果是有很多有两个字段（不算表的自增id）的链接表，这样表特别多，维护起来有点麻烦。而且这样的话还总是需要设置 on delete cascade 等等，有点麻烦。不知道自己所做的方式是不是正确的方式，没有数据库专业人员辅助自己设计这么多表也有点慌...以及这种情况有没有稍微清晰的一点方式呢？以及有没有什么隐患？

Answer 1

我的建议是
1.去掉on delete cascade，使用程序关联删除，因为使用on delete cascade会消耗数据库资源
2.如果觉得表特别多，那数量究竟是又多少呢？能不能使用ER图的形式标示出来，不管是DBA或者是其他开发人员心里都有底
3.是不是真的有那么多多对多的关系呢？其实有些需求应该是莫须有的，建议review一下是否真有那么多多对多的关系。
举个例子，只是举个例子：
从一个公司的层面上来说，不会存在一个人在两个部门的情况
那在表设计的时候完全不需要考虑多对多的情况，直接一对一就好了。