关于表设计，冗余字段的取舍
在做一个处罚系统时遇到的困惑：
在一条处罚信息中包含了笔录地点、执法人员姓名、执法证号(非系统录入用户)，如果将这些信息直接跟在主表里，每次都那么几个执法人，感觉数据有冗余。
但是如果将执法人姓名、执法人证号提取出来到一张表，感觉每次查询都要多关联一张表感觉有点麻烦。（因为像这样的字段很多，每次都要提取一张表，感觉会关联到很多表，而且公司的前辈说，在数据库设计的时候关联查询最好不要超过两张表，否则就是设计有问题，因为后期数据量大了，分库分表时会因为关联很多表而不好操作）
所以想请教下大家，什么时候该冗余，什么时候该提取，有没什么好的设计规范。
谢谢
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
正常都是处罚表，人员表，处罚人员关系表。三个表。不知道怎么会都想放一起，分库也就分处罚表，你不分成几个表，人员怎么维护啊，前期简单了，以后怎么办，有你头疼的时候，除非就做着玩，或者以后都没人用
第一第二第三范式之类的，你可以去搜搜。
我记得之前有个正交化设计，就是做到了极致，所有的关联都是外键实现的(query复杂)。
现实项目中，往往不会采用正交化设计，但是也不会采用完全冗余的设计(update和insert复杂)，
具体要看项目的要求。
表本身有点像java中的类，你先要明确哪些东西是可以抽象出来成为一个表的，然后考虑表之间的关系
在正交的基础上，想想哪些列是可以做冗余的
(一般是生成之后就不变的，或者项目中有需求要强制冗余的(之前项目中遇到过，需要和需求那边确认))
同时得考虑CRUD效率的情况，有些时候可以用数据库自己的特性(存储过程，函数等)去处理这些问题。
也有公司倾向于不适用存储过程，函数之类的东西，因为数据更新之后，可能会有不明显的数据更新，同时也会影响到效率
我๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎艹，这名字居然没被屏蔽