什么时候该进行数据冗余，什么时候不该进行冗余？有规则可循吗？该如何处理

什么时候该进行数据冗余，什么时候不该进行冗余？有规则可循吗？
举个例子：

一个部门表， 每个部门有一个ID，另有一个ParentID表示该部门的上级部门，还有一些字段是表示该部门的其它属性）
一张业务表，显示界面上有一个所属部门选择，另有一个该业务表单的统计报表，统计范围是某部门
某时间段内的业务数量

在那张业务表单的SQL表中，我应该怎么存储用户选择的部门？用部门ID吗？这样一开始看起来不错，但当某一部门被合并、变动时问题就来了，
子部门AC是部门A的下属部门，部门A的业务量2月份是100，报表被打印并送到财务科，3月份时子部门AC被合并到B部门下，3月份输出报表时咋一看
没什么问题，但要是倒回去重新输出2月份的报表时会发现部门A的业务量和3月份时打印出来的纸质报表不吻合。如果出季度报表，并根据季度报表
分发奖金时，啊哦...

这就是我想表述的问题，有人可能会说那就把业务报表里的Dept_ID，该为存放某一选择部门的绝对路径如"1|9" 就表示“A部门->子部门”，但部门
还有其它可变动的属性，将来的报表可能也要引用这个属性（谁知道呢），我是不是要连这些属性也一起冗余存储到业务表单里？而且需要冗余什么？ID？
还是它们的Name？我存成个
ID（业务表单ID） Dept_ID（所属部门ID） Dept_Level（所属部门等级）
1 9 二级
还是
ID（业务表单ID） Dept_ID（所属部门ID） Dept_Level_ID（所属部门等级）
1 9 2

555，真是郁闷，这种问题在作业务软件里经常碰到，冗余还是不冗余？

------解决方案--------------------

探讨

我觉得可以考虑这些方面：

1.和财务核算相关的汇总级别，应该考虑冗余记录；财务报表经常追溯历史状态（尤其是跟税务相关的方面），所以一定要保证保留汇总级别信息。例如你提到的部门变更问题，如果财务报表需要追溯部门变更情况并且正确反映历史状态，那肯定得冗余了。
2.和财务核算无关的汇总级别，例如只是一些分析层面用到的grouping，这些就不用啦，或是看具体需要咯。
3.当然也要考虑performance问题，业务系统尽…