因而，我们必须有些盲目地选择一个合理的实现。此外，值得注意的是，即使我们以某 种方式知道（或正确地猜测到）结果集的大小，我们也还是不能保证修改过的实现经过一 段时间后性能不会降低。毕竟，在远程 Oracle 和 DB2 UDB 系统中的数据可能会改变；结 果，以前运行得很好的 servlet 代码可能工作得不再理想了。

使用 DB2 Information Integrator，我们不必担心数据访问的策略，因为系统的全局 优化器负责分析不同的访问途径并选择有效率的一个。

以下摘录了我们的 servlet 中包含的查询 4 的 SQL 代码：

// statements for query #4 q2db2fetch = conn[1].prepareStatement("SELECT c_custkey, c_name, n_name " + 　　 " FROM tpcd.customer, tpcd.nation " + 　　 " WHERE c_nationkey = n_nationkey " + 　　 " AND n_name IN (''JAPAN'', ''CHINA'', ''VIETNAM'', ''INDIA'')"); q2orafetch = conn[2].prepareStatement("SELECT o_custkey, o_totalprice　" + 　　 " FROM orders WHERE o_totalprice > ? "); q2insertfromdb2 = conn[0].prepareStatement("INSERT INTO temp_jquery2a " + 　　 " (c_custkey, c_name, n_name) VALUES (?, ?, ?)"); q2insertfromora = conn[0].prepareStatement("INSERT INTO temp_jquery2b " + 　　 " (o_custkey, o_totalprice) VALUES (?,?)"); q2tempselect = conn[0].prepareStatement("SELECT c_custkey, c_name, " + 　　 " o_totalprice, n_name " + 　　 " FROM temp_jquery2a, temp_jquery2b " + 　　 " WHERE c_custkey = o_custkey"); q2tempdelete1 = conn[0].prepareStatement("DELETE FROM temp_jquery2a"); q2tempdelete2 = conn[0].prepareStatement("DELETE FROM temp_jquery2b");

跨多个数据源的J2EE开发: 细节探讨(10)

最后，查询 5 结果是这几个查询中最有技巧的一个。这里我们需要找出订单的平均成 本，这些订单是一部分满足条件的客户对整个（合并）公司下的。我们不能仅仅拿出针对 每个数据源而计算的平均值；当我们跨 所有数据源来计算每个满足条件的客户的订单平均 值时，我们最终得到的结果将是不正确的。但是不能成功地将某些聚集操作叠加到每个数 据源将产生大量的数据传输，其中很多是不必要的。

相反，我们决定对每个后端数据源发出 COUNT(*) 和 SUM 函数来计算每个客户的订单 数和这些订单的总成本。通过合并这些信息（以及我们客户的其它数据），我们可以跨所 有数据源来计算每个满足条件的客户所下的所有订单的平均金额。

认识到要按这种方式来修改我们的查询以保留我们的语义和维持合理的性能需要一些思 考。但是这是事情的唯一部分。因为原始的查询按其它方式限制满足条件的客户，我们想 要利用这些增加的搜索谓词来进一步最小化不必要的数据传输。

最后，我们为远程 DB2 UDB 编写了一个非常具有限制性的查询，来获取所有满足条件 的客户和有关订单数量信息以及他们所下订单的总成本信息。这些信息放入一个辅助表。 然后我们能够使用此表中的唯一客户标识（CUSTKEY 信息）来进一步限制从我们的 Oracle 和 Excel 系统返回的结果。如果我们在那里找到任何匹配的行，那么我们对每个客户计算 订单的总数和这些订单的总成

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!