这次的项目有点特殊：分布式项目，需要多系统交互。我们的项目，就需要其他开发组提供很多接口。
分布式项目，有两种实现思路：
一是拷贝数据，将其他系统的数据拷贝到本系统；
二是与所需系统共用一份数据，由一方维护数据。
分布式项目，数据不一致问题是一个大问题。
这里，第一种情况会遇到更多数据不一致的问题。之前设计考虑到共用一份数据时，无法保证事务的问题，所以选择第一种方案。
解决方案是：将用到其他组的数据，导入到本项目对应的数据库中，并在这边建立相应的表结构容纳数据。
例如授课信息表采用类似于如下的方式存储信息：
实际情况中，这边需要多次用到学生、课程、教师等信息，那么就多次冗余学生、课程、教师等这些信息。
这样设计你乍一看一定觉得蠢死了，反正给我的第一印象是这样的：如果想要变更学生信息，就要在多个地方同时去修改，容易出错不说，还冗余很多数据字段，最多你存个Id不就得了。然而随着加深对业务的理解，你会感叹这一设计的智慧。
这样设计的优点：
1、实际情况下，每年都会有遗漏的或授错课的情况，这是就需要再次添加授课信息。这样设计实现起来很简单，根据日期查一下子，把新授课的信息拷过来就哦了，可以说，这样设计，屏蔽了很多问题；
2、查询的时候非常方便，显示字段与数据库本表的字段基本吻合，不用对几十万条数据的表进行多次查询；
3、对硬件要求较低，由于本系统设计大量查询，查询速度非常关键，这种设计极大程度上保证了查询速度；
4、本系统几乎不涉及数据修改，所以数据一致性能够得到保持。
所以说，这种存储冗余字段的方式，比只存id的方式好的多。只存外键id，界面显示的全是name，那么你一个查询少说就涉及到了十几张表，而且是数据量非常大的情况。不得不说：在这种维持两份数据的实现思路下，这种设计看似笨拙，实则规避了很多问题，大智若愚。
现在项目中使用Ejb，事务可以交给Ejb处理，所以现在想要换第二种实现思路：与公共开发组共用一份数据。
这样就极大程度上避免了数据不一致的情况，能够保证两个系统最新数据的同步。与此同时，由于本系统中不再存储公共模块儿的数据，会出现信息丢失的情况。这就要求，我们系统中必须设定历史表，历史表里面可以尽可能全的存储信息。
这时，面对授错课、多授课等情况时，我们要做的就是始终与基础模块保持一致。设置学生学科临时表，里面只存一个基础模块儿的学生选课表的id，学生评教时，实时写入id，评完后与基础中的表的id进行比对，删除对于信息后，就能够保持数据的正确性与一致性。
不过，这时不再冗余数据，查询的速度估计会成为最大的问题。
原文：http://blog.csdn.net/liu765023051/article/details/18602189
