系统分析设计 一个JOIN问题解决方案的感想 重视业务分析设计

转载于：http://www.cnblogs.com/RicCC/archive/2006/12/31/Architecture-Business-Analysis.html

 

 

Richie
    2006-12-31
    RicCC:http://www.cnblogs.com/RicCC/archive/2006/12/31/608925.html

 这是某个系统的一个做法，觉得对架构师在系统分析设计思想上有所启发，所以写出来跟大家分享。
    一个大系统，业务和系统都非常复杂，系统很灵活，但是后台提交到数据库的SQL语句，基本都是最简单的SELECT、DELETE、UPDATE、INSERT，你看不到复杂语句的出现，包括JOIN。而对于我们自己开发的系统，哪怕再简单不过，不使用JOIN似乎不可能。

    用一个简单的例子来说明。有一个销售订单对象，它会关联到客户对象。我们假设客户对象以一个客户编码作为主键，值是唯一的，然后会有客户名称、地区/城市、地址等资料。销售订单表有一个客户编码字段，跟客户对象关联。用户需求可能是通过客户名称、地区/城市等相关信息查询销售订单。

    这种情况下，有一种设计方案，是在SalesOrder表中建立一个CustomerName字段，销售订单创建的时候就把客户名称的值带过去，在查询上只允许按照客户名称对SalesOrder表进行查询，避免使用SalesOrder表与Customer关联。这种方案的优缺点，大家会有各自的看法。首先，如果需要添加按照客户地区/城市来查询SalesOrder，得在SalesOrder添加客户地区/城市的字段，如果还有其它的对象跟SalesOrder关联，可能也得添加字段用于查询；其次某些情况下，这种用法能够跟业务需求比较好的吻合起来，但大部分情况下，如果客户名称有发生变化，怎么办？维持SalesOrder表中原有的客户名称值不变，还是对所有添加了客户名称的表进行同步更新？如果不是因为业务需求确实需要这样做，这种做法是不大合理的。
    接下来看一些比较常规的做法。直接写SQL，使用SalesOrder Inner Join Customer进行查询，或者使用HQL，或者在ORM上配置对象关联关系等方式实现。
    首先，如果在ORM上配置关联关系实现，一旦查询复杂一些，并且系统这种查询很多，会使系统实现或配置很复杂。所以对于这种情况，ORM都会尽量避免，要么直接使用SQL，或者象Hibenate使用HQL实现。
    直接使用SQL时，一方面造成业务模型对逻辑封装的泄漏，另一方面是对数据持久化媒体的直接暴露。使用HQL能够做到一些弥补。
    最后我们从性能和效率方面分析一下。
    不管是ORM配置对象关联关系来实现，还是使用HQL，最终框架都是生成Join语句进行数据库查询。SalesOrder和Customer只是一个最简单的示例，实际中大家遇到的关联需求可能极为复杂。因为业务的复杂性，对关联表中索引的需求也是多样的，难以保证每个查询以最高的效率使用索引。比较极端的情况，也很可能常遇到，象上面的例子，可能需要先对SalesOrder和Customer两个表做全表扫描，然后对这两个表所有数据进行Join操作。假若SalesOrder和Customer都是几十万、几百万的数据量（当然这种数据量下肯定不会让这种事情发生，只是举例），这个查询性能会是什么样子？SQL Server也好Oracle也好，都会非常差的。可能不少的系统都会面临一些复杂查询的性能问题，解决起来确实比较棘手。
    在数据量没有这么多，能够在一定程度利用索引的时候，情况会好一些，但这也只是限于一定的情况下。各方面的原因，都可能造成我们难以确保所有复杂查询都充分利用索引，随着业务数据的变化，索引的使用效率也会发生变化。当单个的查询对数据库服务器造成比较大的消耗时，并发数越大，系统的性能下降越厉害，并且带来一系列互相关联又互相影响的问题，阻塞严重，死锁概率变大。对稍复杂的系统，出现这种情况时，在系统层面做优化有可能是件无法实施的事情，因此不少的系统会选择将过期的数据导出。
    另外效率方面是指，如果这个查询结果比较多，绝大部分情况下对于用户而言这是一个无效查询，因为用户不大可能在大量数据里面再去检索他想要的数据。面对这种情况，用户极有可能会凭记忆，查文档查邮件等其它方式找到一些更精确的条件，缩小查询结果的范围。有的人会提出，结果集是按特定字段排序的，用户拉动滚动条、翻页等可能会比较方便的找到他想要的数据。对于CS下面的产品，这的确是有可能，在BS上，我们不可能一个页面显示太多数据，翻页去找用户一般是不大愿意的，并且，对于那些被用户忽略的数据，我们还是白白耗费了服务器资源，是否有更好的方式避免这种情况呢？另外有的人可能会提出，添加一个类似SQL Server里面的Top语句，或者使用Oracle的Rowid限制结果集数量。其实这种做法在上面示例的情况下，除了减少网络传输方面比较明显，在数据库查询方面并不能带来多少效率的提高，因为数据库仍然得完成Join等操作之后，才能知道Top或者是Rowid所指定的范围，你从执行计划里面都可以发现这一点。这种低效的查询，耗费服务器资源做无用功，当你看着服务器内存、CPU、I/O消耗很高，而执行的查询有效性却比较低时，作为架构师、设计师的你，会有什么感想？

    其实，过于复杂SQL的出现，复杂SQL所带来的系统性能问题，本身就直接意味着系统架构、分析设计、开发方面的问题。
    象上面提到的那个系统，不使用一个JOIN，大家可能会觉得它走了一个极端。它是通过在系统分析、设计上下足功夫来实现的，在下面了解它的做法之后，我们能够知道，它的做法增加了一些与数据库的交互，在用户多的情况下并发情况可能会稍严重一些，但跟上面的分析相比较，这绝对是不足以提的。并且这种情况下遇到的数据库性能问题，我们可以认为是一种正常的良性的状态，是一种必然，通过提高服务器配置，调整数据库服务器架构等，能够比较容易和明显的改善，而不用调整系统。

    一般的做法下，使用JOIN方式，界面差不多是这个样子，这也是很直接很自然的一种方法：

    为了避免使用JOIN，界面就只允许按照客户编码的字段进行查询了，界面的样子如下：

    当用户需要根据其他客户资料查询销售订单时，将这个操作拆分成两个步骤。第一步根据客户的其他资料先准确查询到这个客户，这个步骤通过Customer NO.查询条件输入框后面的图标按钮，弹出一个详细的客户资料查询界面。当准确查询到某个客户资料并确定之后，弹出的客户查询界面将客户编码返回，填入到Customer NO.查询条件输入框中。第二步就是根据返回的客户编码查询销售订单。
    当然你可能会想说，这种做法用户使用起来不方便，因为只有一个客户编码的输入框。作为系统分析设计人员，需要能敏锐地觉察到这种问题，一个订单查询的用例，经过这样分拆之后，可能的确给用户的操作带来局限性，所以需要进一步思考完善。看一下下面的界面：

    首先，Customer NO.输入框有多组，用户可以输入多个值进行查询；在第三行Customer NO.输入框位置有一个向下的图标按钮，点击之后可以动态添加一组Customer NO.输入框。其次一般的系统，象这种客户编码、销售订单编号等，都是有规则的，相同的前缀可能意味着属于同一个类别，因此每一组Customer NO.条件都使用From、To的查询方式，就是说那些 From值 =< Customer NO. =< To值。另外，假如你有一个Excel文件，里面有10个客户编码的列表，现在你需要查询这10个客户某个月份的销售订单，一个一个输入可能还是比较麻烦，这种情况下可以提供一个上传查询条件列表文件的方式，避免用户频繁输入。
    说明一下，参考的系统是CS结构，在BS上实现可能有些繁琐复杂，我们不去探究这些方面，而是把它当作一种分析设计方法参考。
 
    从效率和性能方面分析一下。将原本需要JOIN完成的查询拆分成了两个步骤进行，每一步都是进行一个单表查询。在单表查询的基础上做性能方面的考虑，这个问题就变得非常单纯，容易很多，例如索引的建立和使用，使用Top、Rowid等方式提高数据库的使用效率和查询性能（默认返回500、200条记录，用户可以输入具体的数字到底返回多少条）等。如果你对数据库的理解比较透彻，用前面提到的SalesOrder和Customer都是几十万、几百万数据量的情况做一下对比，如果再加上Top、Rowid等方式的使用，用户完成同样的一个任务，数据库的开销可能是1个甚至几个数量级的改善。
    在系统开发方面，简洁、清晰。一个客户查询对话框，可以在所有类似使用客户资料进行查询的地方使用。数据列表的显示只是基于单个对象，有利于做成通用的控件、组件方式，比较自然的嵌入在整体技术架构中。如果查询条件部分也能够控件化，你的系统界面开发会是一个全新的面貌。
    在架构设计方面的优点，大家可以想到的可能更多。原本一个用例需要结合两个对象一起考虑，现在每一步骤只是针对一个对象操作，这样有利于业务对象逻辑的完整封装。对复杂关联关系的考虑，造成技术框架方方面面的复杂性，随着这个拆解消失。例如ORM，如果不需要关联关系，不需要HQL，根本不需要考虑开发者会自己定义一个查询，返回一个比较随意的DataSet而不是Domain Model Object，你对ORM的开发、选择还会有什么考虑？
    复杂的系统逻辑，并不会因为上面这样一个简简单单的方案就能解决所有的JOIN问题，不同的场景下你需要进行不同的分析，例如有的情况下适当的添加冗余表、冗余字段等。

    啰嗦的写了一大段，并不是想告诉大家这里有这样一个解决JOIN的方法，大家以后不要用JOIN了。而只是想结合在这样一个示例中说明一下业务分析、设计的重要性。很多时候我们太过依赖于技术而忽视业务分析设计，而去追求一组互相矛盾的目标：开发维护高效方便、系统灵活扩展性伸缩性良好等等，因此我们开始进入一个漫漫的旅程，对技术的要求越来越高，对框架的要求越来越多也越复杂，而你却始终都发现还是难以接近目标。如果你在业务分析设计上多花一些精力，可能取得的效果会完全不一样。
    最后祝大家新年快乐！