DB2 J2EE开发成本收益分析(三)_Java教程

　　基本servlet设计

　　我们使用标准JDBC调用来构建我们的servlet，通过DB2 Information Integrator和本地客户端接口（无DB2 Information Integrator）访问数据。只要有可能，我们就使用DataSource连接（连接池），这样能够更有效的利用系统资源。更进一步，我们通过执行JNDI在每个servlet的init方法中查找DataSource，设法维护编码效率。

　　当我们通过DB2 Information Integrator访问远程数据的时候，我们的servlet发出针对别名或者跨多个别名的UNION ALL视图的查询。当直接访问远程数据的时候，我们的servlet发出针对每个数据源的查询。然后，我们必须确定如何整合返回的结果。

　　我们可以在我们的servlet中手工完成这些整合工作，编写必要的代码根据需要组合、分类和分组这些数据。然而，这将会有很大的工作量。取而代之，我们选择利用一个本地DBMS表来帮助我们的工作，我们这么做的原因是这样的软件对于大多数WebSphere开发者也是有用的。在从每个数据源检索到适当的数据以后，我们的servlet把结果插入一个本地DB2数据库的辅助表中，并且查询这些表以获得最后的结果。当然，我们试着去过滤尽可能多的位于远程数据源的数据，来最小化网络通信量并进一步提高我们的本地servlet的效率。

　　假如这听上去很含糊，那么让我们研究一个简单的例子。想象我们需要构建一个servlet，不使用DB2 Information Integrator，报告一套零件的最低供给价格。在与我们三个数据源中的每一个连接之后，我们的servlet将查询每一个数据源上PARTSUPP数据，来找到这些零件的最低供给价格。（SQL语句可能看起来像Select MIN ( ps_supplycost) from PARTSUPP where ps_partkey IN ( list of ps_partkeys) group by ps_partkey。） servlet然后将把价格信息储存到一个本地临时表中，这个表两个列：ps_partkey和ps_supplycost。最后，这个servlet可能发出一个针对本地表的查询，计算最小的ps_supplycost值，使用ps_partkey分组。

　　紧接着，是实现我们直接使用直接数据访问的servlet的基本程序逻辑。当然，程序比仅仅编写一个简单的查询要更复杂，我们要编写当我们使用DB2 Information Integrator进行数据访问的时候，我们要做什么。但是到底有多复杂呢？请接着向下读。

　　现在，你可能对我们从我们的工作中了解到的东西感到好奇。我们将在本文中总结我们的结论，然后在后续的文章中向你说明我们怎样得到这些结论。但是归根到底还是那句话：我们发现，当我们使用DB2 Information Integrator的时候，构建servlet更为轻易。

　　为什么？因为使用DB2 Information Integrator (II):

　　　· 我们需要实现的数据访问逻辑要少些。大约少40%的代码量。

　　　· 我们不必为如何把我们的查询正确地分解为用于每一种目标数据源而担心。这节省了我们无数的时间和沉闷的调试工作。它还让我们更加轻易获得我们想要的结果！

　　　· 我们不必协调我们的数据访问程序逻辑。比如说，我们不必研究我们的数据是如何被分配以便作出适当的联接过程程序逻辑。我们让DB2 II的优化程序为我们做这些工作。通常它能做得很好，有时甚至比我们手写的程序更要优秀。 设计数据访问程序逻辑

　　因为我们的servlet是数据集中的，它们的代码大多数包括数据访问程序逻辑。利用DB2 Information Integrator，我们的servlet连接到单一的基本数据服务器，发出单一查询，然后分布它们取得的资源集。假如不使用DB2 Information Integrator，我们的servlet分别连接到每个数据源，每个数据源至少要发出一条查询，把从每个数据源中检索得到的数据放入至少一个本地临时辅助表中，付出用于辅助表的（最后）一个查询，清除辅助表的内容，发布它们取得的所有的本地的和远程的资源。

　　当然，这需要更多的编码要实现。此外，假如没有DB2 Information Integrator，它会花费我们成倍的时间来实现我们的servlet，因其工作的复杂性。并且这个复杂性的大部分是如何把每个查询都正确的分解为针对每种数据源。

　　取得正确的查询

　　当直接使用不同的数据源工作的时候，我们知道我们必须发出针对每个数据源的查询，取得结果，并执行一些最终操作过程来返回我们寻找的信息。要想不花费我们很长时间去实现为每个远程数据源都发出查询是很不轻易的。

　　为了保证我们的本地实现的性能，我们得尽可能多地过滤每个后端数据源上的数据。例如，查询2包含一个WHERE子句，指定一个特定的零件键值。这种检索谓词相当有选择性，并且应被推到数据源以避免不需要的数据传送。

　　不幸的是，并不是所有查询都可以简单的协调连接到每个数据源。带有某些聚合函数和FETCH FIRST n ROWS子句的查询需要被非凡小心的处理。有时，当你试图合并最后的结果的时候，把它们推到每个后端数据源可能导致不正确的信息。

　　假如这听起来有点含糊，那么我们将在下一篇文章中带你进入一个具体的例子。你会看到，在不破坏我们的查询的语义的情况下，我们是不能在查询5中传送AVG函数的。取而代之，我们必须使用SUM和COUNT(*)函数，用于我们的后端数据源查询。然后，在我们合并结果到一个辅助表之后，我们必须把数据分为两栏，并且针对每个客户计算平均值。

　　这样，确定如何正确地分解复杂的查询，以便性能不受损害以及我们工作的完善性不会被破坏，就变成了一个耗时的并且易于出错的过程。然而，值得一提的是，DB2 Information Integrator可以为你自动的治理这个困难的任务，作为它全局查询最优化工作的一部分。

　　确定数据存取策略

　　我们的一些查询包括不同地址的两个以上表的连接。尤其是，查询4和查询5有这个特征。假如你熟悉关系数据库治理系统，那么你应该知道所有支持用于高效处理的多连接方法的主要商业产品。表的大小和索引的有效性可能较大程度地影响这种数据库治理系统优化程序可能为一个给定的查询选择的用来保证其性能的连接方法。

　　当你必须在没有联合数据库治理系统的情况下，连接跨不同数据源的数据的时候，你必须担负起如何有效地处理连接的责任。最简单方法--检索来自每个数据源的所有的行并且在本地治理连接--可能导致很差的性能。但是得到最好的方法并不是那么轻易，尤其是假如你没有访问一个全局目录的权力的时候，你就得不到关于远程表和索引有效性得统计数据。

　　我们必须面对我们的一些查询中的问题，我们很快发现对于数据分布不同的假设可能导致我们采用不同的方法来实现我们的servlet程序逻辑。并且，假如我们的数据分布情况将来将改变，假如新的索引被创建，或者假如现有的索引被删除，那么我们的servlet的性能可能会下降，可能会迫使我们又要修改我们的代码。这是另一个如何使用联合数据库治理系统的例子，能让我们使用很少的工作量就可以完成我们的开发工作。

　　总结

　　构建需要整合来自于多个数据源的数据的网络组件不是很平常的任务。幸运的是，联合数据库治理系统技术的新发展帮助我们减轻了很多做此类相关事情的负担。

　　我们构建需要整合来自多个数据源的数据的servlet。一类使用DB2 Information Integrator，而另一类直接访问每个数据源。我们的经验显示，当我们使用DB2 Information Integrator提供访问不同数据源的透明性的时候，设计、开发和维护工作明显减少。在我们的例子中，我们减少了代码量达40%。此外，我们不必进行试图确定如何有效地分配我们的查询到每个数据源，以最小化不必要的数据传送这个令人烦恼的、耗时的任务，同时仍然能够保持我们工作的完善性。我们通过依靠DB2 Information Integrator固有的全局优化能力完成这个任务，它答应我们在保持性能的同时获得正确结果。(全文完)