来个头脑风暴^ - ^一个技术层面的挑战：异构数据库之间的联合查询

这种情况目前似乎没有很好的办法，不太相信中间件可以做到高效，而且当数据量很大的时候，即使不跨表计算，性能都不可能很好。

如果是不需要在线计算的功能，那完全可以用mapreduce的方法离线计算。
如果是一定需要在线计算，要很好的性能，可能要考虑自己索引数据或者先算好缓存起来。总之对于跨多个服务器，多种数据库，还想SQL运行起来跟在自己机子上跑个例子那样好的效率，估计很难。

其实这个问题的难点在于,不同系统之间是使用不同的数据库, 如果这些系统都是使用同一种数据库好解决了,比如都是DB2,都是ORACLE,都是MYSQL, 但这种情况真是太少了, 我目前只是在实际中使用到了DB2,使用自带的数据库联邦来实现,在本地数据库可以访问其它系统开放给我的表, 不过IBM有类似软件,可以实现此功能,

做個跨數據源的SQL引擎，將原始SQL語句按訪問的對象解析為多個單數據源能执行的SQL語句，將查詢結果集返回到上層SQL引擎做其它處理。

舉例說明之：

select a.*,b.* from db1.t1 a db2.t2 b where a.c1=b.c2 and a.c3>10;

db1.t1 處於數據源ds1,db2.t2處於數據源ds2，則上述SQL語句就會被解析為

                        filter a.c3 >10

                                 |

  join resultSet(a) and resultSet(b)

                  /                        \

                 /                          \

                /                            \

select * from db1.t1         select * from db2.t2

如果有这个需求，时间允许，完全可以自己做一个中间件。将所有需要查询的数据，汇集到这个中间件里面，根据业务逻辑，查询结果。类似内存数据库。

正好遇到了同样的场景。
方案是用后台引擎实现这类跨库关联查询，用中间件保持数据库和引擎的数据同步。

内存数据库有2个优势，一个是io快，一个是可以作为中间库（排除sql的差异）。自己做中间件的话，工程量比较大，而且对性能要求较高

还是用个中间数据库，或者统一数据库产品比较好。像SAS这样的公司做OLAP产品，也是用了中间数据库的

其实解决这个问题还有个最傻的也肯定有效的办法：就是最原始的，让程序员自己去判断数据库类型，用了什么数据库，就写什么样的SQL，把不同数据库的数据都提到内存里来进行一致性处理。

自己写中间件去做这事情是最不靠谱儿的，投资大，见效慢，效果差。

经手过一个过亿的项目.
把现有的N个系统整合起来.
N大于等于20
当下决定跳槽.

多库联合查询？为什么不用JTA呢？