项目一：Distributed Software website
项目简介（功能与用途）：
Distributed Software website(DSW)是IBM面向全球用户的在线销售软件的网站。通过该网站，IBM公司的销售人员，软件分销商和软件购买者等各种角色的用户根据权限的不同可以进行在线注册，认证，寻价，下单，签约，续约，下载软件，查询并维护软件许可证，以及寻求技术支持等操作。本人在该项目中进行了大量数据库相关的设计开发工作。
项目难点与解决方案：
IBM拥有极为庞大的软件产品线。而IBM的软件销售策略根据购买者所在区域、国家、类型、规模、购买数量、所经渠道的不同都有特定的规定，因此业务逻辑极为复杂。而又由于IBM在全球的软件用户数目众多、加之每天累计增加的数以万计的软件交易数据，整个数据库的数据量极为庞大。由于在线交易网站自身的特点，要求任何包含复杂查询的网页的相应时间均需要在用户的忍受范围之内，因此对性能的要求也非常之高。另外，因为数据库中包含大量敏感的用户数据，一旦被恶意用户攻破，IBM软件用户的利益将有可能受到无法估量的严重损失。所以，数据库的安全也是本项目要考虑的一大重点。
在使用了高端的数据库服务器，数据库集群、选用全球数据存储量第一的数据库产品DB2等系统级解决方案后，作为软件工程师，更多考虑的是软件级的解决方案。在数据库设计阶段，要调整数据参数，根据业务和查询特点创建表、主外键和索引。在开发阶段，因为数据库存储过程在处理复杂数据库操作时具有最为优异的性能，并且存储过程又能够包含一定的业务逻辑，所以我们使用存储过程来提高数据库查询性能。基于安全方面考虑，我们更是将全部数据操作均使用存储过程实现。因此，我们就可以根据业务的不同分别创建不同种类的帐户，每种帐户只能访问包含访问特定类型业务逻辑和数据的存储过程。除非在特殊情况下，任何帐户均没有直接查询数据库表的特权。同时我们拥有有一套严格的流程来管理数据库帐户。这样在软件和流程级别最大限度的保证了数据的安全。
项目成功与失败的经验归纳：
DSW项目已经有十多年的历史。随着业务需求的不断变化和客户要求的不断提高，该软件一直以每年成功发布两个主要版本的速度进行着升级。本人参与的全部4个主要版本的升级工作全部都按时保质的成功发布了。因为项目是在原有的系统上升级，数据库方面大量的工作集中在在原有数据上创建表、视图、存储过程和用户自定义函数（UDF）上。因为是与包括美国、英国、新加坡等国家的数十位开发人员共同协作开发，要求各团队成员所开发出的数据库对象拥有一致的风格，以保证其他团队成员能够方便进行升级维护。同时，要求任何成员在修改了原有的数据库对象后，对其他团队成员影响降到最小。
经验1：开发、测试和生产数据库要分开，并且它们在开发初始阶段要拥有相同的数据对象和相似的数据。这样可以保证开发、测试及其生产环境互不干扰，同时开发、测试数据库能够最大限度的模拟生产环境，保证系统部署时的顺利。
经验2：在开发之前，为整个开发团队制定一套统一的开发流程的模板，新成员所开发出的代码提交之前要由资深成员检查代码，以确保各个成员所提交的代码拥有一致的质量和风格。
经验3：整个开发团队使用统一的版本管理工具。必要时在主版本外创建分支版本。保证软件版本的一致性。
经验4：如在开发过程中需要改变某些共享数据库对象的定义并有可能对其他团队成员造成影响的，暂时使用新创建的对象而不是修改该对象。等开发到特定阶段后再统一更改此类对象的定义，以降低对其他团队成员的影响。
经验4：开发过程中，应使用各种数据库开发技巧来提高数据库操作的性能。使用复杂查询时，使用DB2中的“说明SQL”工具检查该SQL的性能并作出相应调整。
你在项目中岗位与贡献：
本人在项目中担任软件寻价和下单模块部分中国团队的项目组长。负责与美国团队沟通需求，制定、修改开发流程和模板，商讨技术解决方案，解决技术难题，分配、协调中国团队成员的工作任务并检查团队成员代码。经过各个团队成员的共同努力，成功的完成了的寻价和下单模块的升级工作。
项目二：QuestNet佣金计算系统
项目简介（功能与用途）：
QuestNet是总部设在德国的一家全球性的采用网络营销模式的销售公司。网络营销类似于中国的传销，但在国外一些国家因为有非常规范的经营模式是受到法律保护的。佣金计算系统要求在需求规定的时间范围内，根据公司销售组织结构、销售情况、业务模式，计算出组织结构中从上到下各个销售成员每周的佣金。
项目难点与解决方法：
由于网络营销自身的特点，佣金计算系统是是其信息管理系统中最为复杂部分。首先公司的销售组织结构非常复杂，是一种类似于二叉树的结构，数据库中只存储了组织结构中的上下线关系，系统需要根据上下线关系快速地建立类二叉树的数据结构以方便后续的佣金计算。在计算佣金时，由于系统中只存储了每笔交易的数据，系统需要根据全部的交易数据、销售人员在组织结构中所在位置、以及向上级返点的业务逻辑计算组织结构中涉及交易的全部人员的点数。在计算过程中，随着交易量的变化，相应成员的也会有升职或降职的变化。这种变化要及时反映到类二叉树的组织结构中并立即导致点数计算公式的变化。最后，要将计算结果转换成本周的佣金存入数据库，并将发生变化的数据全部存入数据库中以备下周的计算。数据库中组织结构，成员上周点数和级别、交易数据等表地数据量级均在数十万。因此软件不可避免的要读取这些表中地绝大部分数据，进行相应递归式的运算、最后在数据库中的几个表中插入或更新总计十几万条数据。而性能需求要求所有的这些操作必须在10分钟内完成。
经过分析，软件性能的瓶颈发生在插入或更新发生变化的十几万条数据时。在使用了高性能数据库服务器、调优了数据库参数和表索引后，使用动态SQL完成全部操作仍需要近1个小时。而因为存储过程只能显著提高相对复杂的数据操作，只将插入更新时的动态SQL改为用存储过程实现并不能显著提高多少性能。而考虑到存储过程不能在内存中构造类二叉树的数据结构，将全部计算逻辑用纯存储过程实现同样不可行。最后，我们采用了SQLJ技术满足了性能需求。即在系统初始时将数据库中所需全部数据读入内存，在内存中构造类二叉树的数据结构，计算完毕后使用SQLJ将十几万条数据写入数据库。因为SQLJ同存储过程一样属于静态SQL，虽然在处理复杂逻辑时SQLJ性能不如存错过程，但由于经过与db2绑定后的SQLJ类已经成为了DB2中一个package，因此调用时会极大减少网络传输的消耗。我们在改写了全部涉及数据库操作的java文件为SQLJ后，整个程序的执行时间戏剧性的减少到了3分钟。比性能需求中要求的10分钟快3倍。
项目成功与失败的经验归纳：
该项目成功实现了功能需求并超过了性能需求的三倍。
经验：在功能和性能需求要求极为苛刻时，选择合适的技术是完成需求的关键。以下是关于静态SQL、动态SQL使用的一些心得。
1. 动态SQL提供给了开发人员极大的灵活性，一般表现为在代码中直接嵌入SQL语句。但由于动态SQL需要在执行前编译，效率要相对静态SQL低。可在系统性能需求不高时使用。
2. 静态SQL在执行前已经在数据库中完成了编译，因此执行效率要比动态SQL高很多。存储过程和SQLJ均属于静态SQL的范畴。但因为静态SQL要求在编写代码时就确定SQL语句，比动态SQL少一些灵活性。
3. 在SQL语句中包含复杂逻辑时，执行效率从高到低为：存储过程，SQLJ，静态SQL。但当SQL语句趋于简单时，这种性能差别逐渐缩小。在SQL语句简单到一条单独的查询语句时，这种性能差别可以忽略不计。因此，如果要在数据库端处理复杂的逻辑，从性能方面考虑应使用存储过程。
4. 由于调用存储过程时所用的字符数目通常会比一条动态SQL中包含的字符数目少，使用存储过程也会因为减少了网络传输而使性能提高。但对于复杂SQL来说，使用存储过程因网络传输减小所带来的性能提高通常不如预编译所带来的性能提高效果显著。
5. 因为整个包含SQLJ语句的Java文件在绑定后已经成为了数据库中一个package，与在Java代码中使用JDBC调用存储过程相比，SQLJ使用更少的网络传输。这种差别在大量调用简单SQL语句时表现得非常明显。因此，如果要执行大量的简单数据库操作，从性能方面考虑应选择SQLJ。
你在项目中岗位与贡献：
本人在项目中担任技术负责人。负责与客户沟通需求，选择技术方案，分配任务、编写关键模块代码及控制软件质量。通过选用SQLJ开发技术，成功的达到并超过了客户要求的功能及性能需求。
项目三：易宝商讯股票交易系统数据库迁移
项目简介（功能与用途）：
易宝商讯股票交易系统原来是部署在SQL Server2000数据库上的，项目要求将数据库系统改为DB2。需要迁移的数据库对象包括表、视图、索引和存储过程。
项目难点与解决方法：
因项目实施时间较早（2001年），当时还没有较成熟的数据库移植工具。因此大量的移植工作必须由手工完成。
因为SQL Server和DB2的数据类型间有较明确的对应关系，表、视图、索引的迁移相对简单。我们可以采用数据库建模工具（如ERWin或PowerDesigner）先作反向工程从SQL Server中导出数据库对象，转换为逻辑视图，作适当修改后，然后再用正向工程将数据对象导入到DB2中。也可以使用正则表达式用字符串替换的办法将SQL Server DDL中的相应数据类型替换为DB2中的数据类型。与移植表、视图和索引相比，比较复杂的是存储过程的移植。SQL Server同DB2在编写存储过程时的语法有很多不同，需要作大量的替换和测试工作。为统一起见，最终我们选用Perl语言使用正则表达式替换字符串的方法完成了全部DDL的替换工作。
项目成功与失败的经验归纳：
项目执行的基本成功，但因为对移植时对所要产生的问题估计不足，为了追赶进度，项目组成员不得不加班工作。
现在看来如果用IBM Migration ToolKit（MKT），移植工作就会顺利的多。MKT提供了一个数据库移植向导，可以从Oracle、Sybase、SQL Server自动的移植表、视图、索引、存储过程甚至触发器。现在最新的MKT已经开始支持MySQL。而且，MKT是完全免费。将来再做类似项目时，我一定会选择使用MKT。
你在项目中岗位与贡献：
本人在项目中担任项目经理和技术经理。负责与客户沟通需求，选择技术方案，制定项目计划，控制项目进度，解决技术难题并保证软件质量。
项目简介（功能与用途）：
Distributed Software website(DSW)是IBM面向全球用户的在线销售软件的网站。通过该网站，IBM公司的销售人员，软件分销商和软件购买者等各种角色的用户根据权限的不同可以进行在线注册，认证，寻价，下单，签约，续约，下载软件，查询并维护软件许可证，以及寻求技术支持等操作。本人在该项目中进行了大量数据库相关的设计开发工作。
项目难点与解决方案：
IBM拥有极为庞大的软件产品线。而IBM的软件销售策略根据购买者所在区域、国家、类型、规模、购买数量、所经渠道的不同都有特定的规定，因此业务逻辑极为复杂。而又由于IBM在全球的软件用户数目众多、加之每天累计增加的数以万计的软件交易数据，整个数据库的数据量极为庞大。由于在线交易网站自身的特点，要求任何包含复杂查询的网页的相应时间均需要在用户的忍受范围之内，因此对性能的要求也非常之高。另外，因为数据库中包含大量敏感的用户数据，一旦被恶意用户攻破，IBM软件用户的利益将有可能受到无法估量的严重损失。所以，数据库的安全也是本项目要考虑的一大重点。
在使用了高端的数据库服务器，数据库集群、选用全球数据存储量第一的数据库产品DB2等系统级解决方案后，作为软件工程师，更多考虑的是软件级的解决方案。在数据库设计阶段，要调整数据参数，根据业务和查询特点创建表、主外键和索引。在开发阶段，因为数据库存储过程在处理复杂数据库操作时具有最为优异的性能，并且存储过程又能够包含一定的业务逻辑，所以我们使用存储过程来提高数据库查询性能。基于安全方面考虑，我们更是将全部数据操作均使用存储过程实现。因此，我们就可以根据业务的不同分别创建不同种类的帐户，每种帐户只能访问包含访问特定类型业务逻辑和数据的存储过程。除非在特殊情况下，任何帐户均没有直接查询数据库表的特权。同时我们拥有有一套严格的流程来管理数据库帐户。这样在软件和流程级别最大限度的保证了数据的安全。
项目成功与失败的经验归纳：
DSW项目已经有十多年的历史。随着业务需求的不断变化和客户要求的不断提高，该软件一直以每年成功发布两个主要版本的速度进行着升级。本人参与的全部4个主要版本的升级工作全部都按时保质的成功发布了。因为项目是在原有的系统上升级，数据库方面大量的工作集中在在原有数据上创建表、视图、存储过程和用户自定义函数（UDF）上。因为是与包括美国、英国、新加坡等国家的数十位开发人员共同协作开发，要求各团队成员所开发出的数据库对象拥有一致的风格，以保证其他团队成员能够方便进行升级维护。同时，要求任何成员在修改了原有的数据库对象后，对其他团队成员影响降到最小。
经验1：开发、测试和生产数据库要分开，并且它们在开发初始阶段要拥有相同的数据对象和相似的数据。这样可以保证开发、测试及其生产环境互不干扰，同时开发、测试数据库能够最大限度的模拟生产环境，保证系统部署时的顺利。
经验2：在开发之前，为整个开发团队制定一套统一的开发流程的模板，新成员所开发出的代码提交之前要由资深成员检查代码，以确保各个成员所提交的代码拥有一致的质量和风格。
经验3：整个开发团队使用统一的版本管理工具。必要时在主版本外创建分支版本。保证软件版本的一致性。
经验4：如在开发过程中需要改变某些共享数据库对象的定义并有可能对其他团队成员造成影响的，暂时使用新创建的对象而不是修改该对象。等开发到特定阶段后再统一更改此类对象的定义，以降低对其他团队成员的影响。
经验4：开发过程中，应使用各种数据库开发技巧来提高数据库操作的性能。使用复杂查询时，使用DB2中的“说明SQL”工具检查该SQL的性能并作出相应调整。
你在项目中岗位与贡献：
本人在项目中担任软件寻价和下单模块部分中国团队的项目组长。负责与美国团队沟通需求，制定、修改开发流程和模板，商讨技术解决方案，解决技术难题，分配、协调中国团队成员的工作任务并检查团队成员代码。经过各个团队成员的共同努力，成功的完成了的寻价和下单模块的升级工作。
项目二：QuestNet佣金计算系统
项目简介（功能与用途）：
QuestNet是总部设在德国的一家全球性的采用网络营销模式的销售公司。网络营销类似于中国的传销，但在国外一些国家因为有非常规范的经营模式是受到法律保护的。佣金计算系统要求在需求规定的时间范围内，根据公司销售组织结构、销售情况、业务模式，计算出组织结构中从上到下各个销售成员每周的佣金。
项目难点与解决方法：
由于网络营销自身的特点，佣金计算系统是是其信息管理系统中最为复杂部分。首先公司的销售组织结构非常复杂，是一种类似于二叉树的结构，数据库中只存储了组织结构中的上下线关系，系统需要根据上下线关系快速地建立类二叉树的数据结构以方便后续的佣金计算。在计算佣金时，由于系统中只存储了每笔交易的数据，系统需要根据全部的交易数据、销售人员在组织结构中所在位置、以及向上级返点的业务逻辑计算组织结构中涉及交易的全部人员的点数。在计算过程中，随着交易量的变化，相应成员的也会有升职或降职的变化。这种变化要及时反映到类二叉树的组织结构中并立即导致点数计算公式的变化。最后，要将计算结果转换成本周的佣金存入数据库，并将发生变化的数据全部存入数据库中以备下周的计算。数据库中组织结构，成员上周点数和级别、交易数据等表地数据量级均在数十万。因此软件不可避免的要读取这些表中地绝大部分数据，进行相应递归式的运算、最后在数据库中的几个表中插入或更新总计十几万条数据。而性能需求要求所有的这些操作必须在10分钟内完成。
经过分析，软件性能的瓶颈发生在插入或更新发生变化的十几万条数据时。在使用了高性能数据库服务器、调优了数据库参数和表索引后，使用动态SQL完成全部操作仍需要近1个小时。而因为存储过程只能显著提高相对复杂的数据操作，只将插入更新时的动态SQL改为用存储过程实现并不能显著提高多少性能。而考虑到存储过程不能在内存中构造类二叉树的数据结构，将全部计算逻辑用纯存储过程实现同样不可行。最后，我们采用了SQLJ技术满足了性能需求。即在系统初始时将数据库中所需全部数据读入内存，在内存中构造类二叉树的数据结构，计算完毕后使用SQLJ将十几万条数据写入数据库。因为SQLJ同存储过程一样属于静态SQL，虽然在处理复杂逻辑时SQLJ性能不如存错过程，但由于经过与db2绑定后的SQLJ类已经成为了DB2中一个package，因此调用时会极大减少网络传输的消耗。我们在改写了全部涉及数据库操作的java文件为SQLJ后，整个程序的执行时间戏剧性的减少到了3分钟。比性能需求中要求的10分钟快3倍。
项目成功与失败的经验归纳：
该项目成功实现了功能需求并超过了性能需求的三倍。
经验：在功能和性能需求要求极为苛刻时，选择合适的技术是完成需求的关键。以下是关于静态SQL、动态SQL使用的一些心得。
1. 动态SQL提供给了开发人员极大的灵活性，一般表现为在代码中直接嵌入SQL语句。但由于动态SQL需要在执行前编译，效率要相对静态SQL低。可在系统性能需求不高时使用。
2. 静态SQL在执行前已经在数据库中完成了编译，因此执行效率要比动态SQL高很多。存储过程和SQLJ均属于静态SQL的范畴。但因为静态SQL要求在编写代码时就确定SQL语句，比动态SQL少一些灵活性。
3. 在SQL语句中包含复杂逻辑时，执行效率从高到低为：存储过程，SQLJ，静态SQL。但当SQL语句趋于简单时，这种性能差别逐渐缩小。在SQL语句简单到一条单独的查询语句时，这种性能差别可以忽略不计。因此，如果要在数据库端处理复杂的逻辑，从性能方面考虑应使用存储过程。
4. 由于调用存储过程时所用的字符数目通常会比一条动态SQL中包含的字符数目少，使用存储过程也会因为减少了网络传输而使性能提高。但对于复杂SQL来说，使用存储过程因网络传输减小所带来的性能提高通常不如预编译所带来的性能提高效果显著。
5. 因为整个包含SQLJ语句的Java文件在绑定后已经成为了数据库中一个package，与在Java代码中使用JDBC调用存储过程相比，SQLJ使用更少的网络传输。这种差别在大量调用简单SQL语句时表现得非常明显。因此，如果要执行大量的简单数据库操作，从性能方面考虑应选择SQLJ。
你在项目中岗位与贡献：
本人在项目中担任技术负责人。负责与客户沟通需求，选择技术方案，分配任务、编写关键模块代码及控制软件质量。通过选用SQLJ开发技术，成功的达到并超过了客户要求的功能及性能需求。
项目三：易宝商讯股票交易系统数据库迁移
项目简介（功能与用途）：
易宝商讯股票交易系统原来是部署在SQL Server2000数据库上的，项目要求将数据库系统改为DB2。需要迁移的数据库对象包括表、视图、索引和存储过程。
项目难点与解决方法：
因项目实施时间较早（2001年），当时还没有较成熟的数据库移植工具。因此大量的移植工作必须由手工完成。
因为SQL Server和DB2的数据类型间有较明确的对应关系，表、视图、索引的迁移相对简单。我们可以采用数据库建模工具（如ERWin或PowerDesigner）先作反向工程从SQL Server中导出数据库对象，转换为逻辑视图，作适当修改后，然后再用正向工程将数据对象导入到DB2中。也可以使用正则表达式用字符串替换的办法将SQL Server DDL中的相应数据类型替换为DB2中的数据类型。与移植表、视图和索引相比，比较复杂的是存储过程的移植。SQL Server同DB2在编写存储过程时的语法有很多不同，需要作大量的替换和测试工作。为统一起见，最终我们选用Perl语言使用正则表达式替换字符串的方法完成了全部DDL的替换工作。
项目成功与失败的经验归纳：
项目执行的基本成功，但因为对移植时对所要产生的问题估计不足，为了追赶进度，项目组成员不得不加班工作。
现在看来如果用IBM Migration ToolKit（MKT），移植工作就会顺利的多。MKT提供了一个数据库移植向导，可以从Oracle、Sybase、SQL Server自动的移植表、视图、索引、存储过程甚至触发器。现在最新的MKT已经开始支持MySQL。而且，MKT是完全免费。将来再做类似项目时，我一定会选择使用MKT。
你在项目中岗位与贡献：
本人在项目中担任项目经理和技术经理。负责与客户沟通需求，选择技术方案，制定项目计划，控制项目进度，解决技术难题并保证软件质量。
1324
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
