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

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

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

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

  • group 信息表,主键 groupId
  • member 信息表,主键 memberId
  • 链接表,有 groupId 和 memberId 两个字段,用于存储对应关系。

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

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

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

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

阅读 2.1k
2 个回答

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

1.表主键用id
2.不用用级联操作,用程序去控制,做软删除

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题