.
现在面对一个相当复杂的业务逻辑,所以试图用中间表切割掉它——
初步估计,这个中间表有120万条数据,但为了业务需要,这个表其实存储了两类数据:每个用户有一条、每周/月/季度的统计数据为一条,status鉴别类型。(见下方表结构)
故而,绝大多数数据的后一类(三个字段),都是空的。(我看数据库内的其他表,有相当多的字段的值都是0或者NULL,才出此下策)
大致的表结构(不严谨):
| userId | groupId | status | sales(99%为空) | createTime(99%为空) | lastTime(99%为空) | endTime(99%为空) |
想了解:
这个数据量的空字段,是否会对效率形成影响?
除了分表之外,还有什么解决方案吗?
这种设计表的活,需要后端程序来做吗?无力感满满的。
.
现在面对一个相当复杂的业务逻辑,所以试图用中间表切割掉它——
初步估计,这个中间表有120万条数据,但为了业务需要,这个表其实存储了两类数据:每个用户有一条、每周/月/季度的统计数据为一条,status鉴别类型。(见下方表结构)
故而,绝大多数数据的后一类(三个字段),都是空的。(我看数据库内的其他表,有相当多的字段的值都是0或者NULL,才出此下策)
大致的表结构(不严谨):
| userId | groupId | status | sales(99%为空) | createTime(99%为空) | lastTime(99%为空) | endTime(99%为空) |
想了解:
这个数据量的空字段,是否会对效率形成影响?
除了分表之外,还有什么解决方案吗?
这种设计表的活,需要后端程序来做吗?无力感满满的。
如果字段不会用到就把他去掉吧
如果有可能会用到留着问题也不大,查询的时候指定需要的字段去查询也没有影响