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

Question

目前在做一个数据管理系统的数据库表设计，但是遇到了这样一个情况：

比如说有两类数据，一类是分组 group，一类是成员 member；
然后每一个 group 还有很多其他信息（比如归属地、类别等等），每一个 member 还有很多其他信息（比如姓名、性别等等）。
group 和 member 是多对多的，也就是说，一个 group 可以有多个 member、一个 member 可以对应多个 group。

所以我目前的想法是设计成三个表：

• group 信息表，主键 groupId

• member 信息表，主键 memberId

• 链接表，有 groupId 和 memberId 两个字段，用于存储对应关系。

但是实际上，除了 member，group 还会和事件 event 也是多对多的关系、还有等等其他的信息，总之各种多对多。

所以这样造成的结果是有很多有两个字段（不算表的自增id）的链接表，这样表特别多，维护起来有点麻烦。

而且这样的话还总是需要设置 on delete cascade 等等，有点麻烦。

不知道自己所做的方式是不是正确的方式，没有数据库专业人员辅助自己设计这么多表也有点慌...
以及这种情况有没有稍微清晰的一点方式呢？以及有没有什么隐患？

Answer 1

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