关于表设计,冗余字段的取舍

在做一个处罚系统时遇到的困惑:

  • 在一条处罚信息中包含了笔录地点、执法人员姓名、执法证号(非系统录入用户),如果将这些信息直接跟在主表里,每次都那么几个执法人,感觉数据有冗余。

  • 但是如果将执法人姓名、执法人证号提取出来到一张表,感觉每次查询都要多关联一张表感觉有点麻烦。(因为像这样的字段很多,每次都要提取一张表,感觉会关联到很多表,而且公司的前辈说,在数据库设计的时候关联查询最好不要超过两张表,否则就是设计有问题,因为后期数据量大了,分库分表时会因为关联很多表而不好操作)

  • 所以想请教下大家,什么时候该冗余,什么时候该提取,有没什么好的设计规范。

谢谢

阅读 8k
3 个回答

正常都是处罚表,人员表,处罚人员关系表。三个表。不知道怎么会都想放一起,分库也就分处罚表,你不分成几个表,人员怎么维护啊,前期简单了,以后怎么办,有你头疼的时候,除非就做着玩,或者以后都没人用

第一第二第三范式之类的,你可以去搜搜。

我记得之前有个正交化设计,就是做到了极致,所有的关联都是外键实现的(query复杂)。

现实项目中,往往不会采用正交化设计,但是也不会采用完全冗余的设计(update和insert复杂),
具体要看项目的要求。

表本身有点像java中的类,你先要明确哪些东西是可以抽象出来成为一个表的,然后考虑表之间的关系

在正交的基础上,想想哪些列是可以做冗余的
(一般是生成之后就不变的,或者项目中有需求要强制冗余的(之前项目中遇到过,需要和需求那边确认))
同时得考虑CRUD效率的情况,有些时候可以用数据库自己的特性(存储过程,函数等)去处理这些问题。

也有公司倾向于不适用存储过程,函数之类的东西,因为数据更新之后,可能会有不明显的数据更新,同时也会影响到效率

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