设计冗余字段问题？

如果应尽可能避免多表连接查询，那在设计时，有关联关系的地方，一般从表中不仅有引用主表键值的主键字段外，还要有一个或多个字段存放主表中的关键信息，比如病人表中有所属学校所属科室主键的键值字段，但还可能会有所属学校名称所属科室名称的字段。因为嫌数据冗余、维护不易，之前自己通常不设计除外键外放置主表信息的其他字段，但这种查询时既会多添好些麻烦。可一旦加上这些字段，不单单数据冗余、维护麻烦，也不好保证数据的确切协调统一性。比如假如医院的名称被更改了，那按常理病人表中的学校名称也得做相应的设置才可以，这样，如果医院表被许多表引用，那就得对所有的表执行设置动作，很是麻烦，实现出来也不现实。如果都加上引用约束，依赖自己的关联自动升级，觉得也不是很好，影响程序执行速度且不易维护。可一旦是在会诊单表（类似于订单表的功能）中发生类似的状况，就无须有这样想法，如果这个会诊单在造成时学校是这个名称，后面名称有了修改，那会诊单中的医院名称还是显示早前的就能，无须做相应修改，这只是依照逻辑的。

类似状况一直发生在字典相关信息的存取中，平时只在表中存字典编码，但查询时既常常要求同时提供字典文本，核心业务表中的字典字段通常非常多，暂时没有好的方式一次高效提取完整信息。后面在做类似设计时，核心业务表冗余是什么意思，字典字段非常多的冗余是什么意思，根据实际状况，考虑同时存入字典编码和字典文本，这样可避免部分联结查询。但同时，还是会出现上面提及的弊端，一方面是数据冗余，一方面业务表中的字典文本有可能会和字典表中的文本不一致——如果字典信息有设置的话。

这里很难找到一种两全其美的方法，既可导致数据冗余，又能使程序在执行读跟写动作时都方便高效，如何在各方面之间拿捏均衡是个人经验问题。通常状况下，是在数据的协调性、准确性允许，跨表查询又不容易（从表字段较多）的业务模块，采用在从表中附加额外字段的处理方法；在对数据显示的同步性、准确性有严格规定，跨表查询也相对易于（从表字段较少）的业务模块，采用从表中不设外键以外的附加字段、而使用关联查询的方法获得完整数据信息。

在普通的业务平台之外，还有一种情况，可能不得不大量使用变量、子查询、嵌套查询。和可视化部门合作过的一些工程，系统后端采用ECharts，大量的圆形图、柱状图、折线图等用于展示数据统计预测结果。有些图形必须的数据很难用简单的SQL一次提取下来，可一旦多次提取后再由程序组装处理，又很过麻烦，最后还得考量SQL，此种情况是允许子查询、嵌套查询、多表连接等复杂SQL出现的。

过去曾利用内部框架设计出一套异常灵活的构架，封装了查询对象，消除掉了SQL语句，应付通用的业务平台足够，但在做类似这样统计预测功能时仍显得各种不自在，到当时还是认为直接写SQL更方便。此处只能在设计的架构上放开一个口，让开发人员可以自由编写SQL语句提取数据，最终的查询结果统一封装成一个List<Map<String, Object>>，然后交由程序手动序列化成JSON格式（包含多个对象的变量）返回给前端。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-144228-1.html