想询问和交流一下数据库表设计的策略,希望大家指点一下?
目前在做一个数据管理系统的数据库表设计,但是遇到了这样一个情况:
比如说有两类数据,一类是分组 group,一类是成员 member;
然后每一个 group 还有很多其他信息(比如归属地、类别等等),每一个 member 还有很多其他信息(比如姓名、性别等等)。
group 和 member 是多对多的,也就是说,一个 group 可以有多个 member、一个 member 可以对应多个 group。
所以我目前的想法是设计成三个表:
- group 信息表,主键 groupId
- member 信息表,主键 memberId
- 链接表,有 groupId 和 memberId 两个字段,用于存储对应关系。
但是实际上,除了 member,group 还会和事件 event 也是多对多的关系、还有等等其他的信息,总之各种多对多。
所以这样造成的结果是有很多有两个字段(不算表的自增id)的链接表,这样表特别多,维护起来有点麻烦。
而且这样的话还总是需要设置 on delete cascade 等等,有点麻烦。
不知道自己所做的方式是不是正确的方式,没有数据库专业人员辅助自己设计这么多表也有点慌...
以及这种情况有没有稍微清晰的一点方式呢?以及有没有什么隐患?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我的建议是
1.去掉on delete cascade,使用程序关联删除,因为使用on delete cascade会消耗数据库资源
2.如果觉得表特别多,那数量究竟是又多少呢?能不能使用ER图的形式标示出来,不管是DBA或者是其他开发人员心里都有底
3.是不是真的有那么多多对多的关系呢?其实有些需求应该是莫须有的,建议review一下是否真有那么多多对多的关系。
举个例子,只是举个例子:
从一个公司的层面上来说,不会存在一个人在两个部门的情况
那在表设计的时候完全不需要考虑多对多的情况,直接一对一就好了。
1.表主键用id
2.不用用级联操作,用程序去控制,做软删除