图灵社区按
TEAP是什么?TEAP是Turingbook Early Access Program的简称,即早期试读,它公布的是图灵在途新书未经编辑的内容。一本书的翻译周期约为3到6个月,如果在翻译过程中,译者就能与读者进行沟通和交流,对整本书的翻译品质是有帮助的。通过TEAP,读者可以提前阅读将来才能出版的内容,译者也能收获宝贵的反馈意见,改进翻译,提高质量。

本书原名为Expert PLSQL Practices,中文暂定名为《Oracle PL/SQL实战》,本篇选自第12章 渐进式数据建模

我的社区ID博客

无论你是在建造飞机还是在构建软件,变化总会发生。你别无选择:你必须管理变化,要不你就会措手不及。

从二十年的系统开发中总结的经验

每个项目都被寄予期望满足快速的设计和实施计划。尽管有些差异,但系统开发的一些基本的现实一直都是相同的。

■客户在看到应用程序之前不知道他们想要的到底是什么。只有当他们看到他们的数据有什么可以做的时,他们才开始了解一个新的应用程序的真实的可能性。也是从这个时间点起,他们将会开始提出项目变更请求。如果你想构建一个优秀的产品,最后你想要做的事情是通过拒绝变更来关闭他们(用户)的想法。

■客户也会撒谎,就像对美剧“豪斯医生”的诠释。(译者注:查了一下,似乎该剧中这个医生十分强硬,导致病人不敢和他说真话)如果让一个客户来描述他们的处理流程,大部分时候他们会用该处理流程的文档中记录的版本来回答。客户不打算误导我们,但ISO认证流程已经教他们用描述目前文档中记录的步骤来回答有关处理流程的问题。然而,很多流程是有缺陷的,很可能还有一些没有被包括在书面文档中的额外步骤。通过观看客户做什么,你会看到真正的处理流程。如果你看到文档中没有的步骤,那就表明你会找到最好的机会,以建立一个创新的产品。

■如果你构建了一个使用户的工作更容易的系统,他们将使用它,并提出更多要求:更多的选择,更多的功能,更高的性能。如果你构建的应用程序所创建的工作,没有为用户提供足够的利益,那么用户会通过他们从未打算或想要完全避免的方式,变通使用该应用程序。对他们而言,这是一个完全合理的反应方式:我们作为应用程序的创造者,应用程序和代码对我们而言是非常重要的;但用户有工作做,我们创作的应用程序可能只是用户日常工作的一小部分。当用户为完成他们的工作,而不得不变通使用一个应用程序时,它们将会产生更多的错误,而数据将随着时间的推移变得不准确。作为数据库和软件开发者,你需要牢记你的客户不会像你一样对技术的细节着迷。用户需要工作保持一致且不出所料的工具。

■如果你不能迅速提供工具或产品,别人会。这既适用于最终产品也适用于内置的开发环境。如果产品上市晚了,潜在客户会找到另一种解决方案以及另一家供应商。如果数据库不能为应用程序开发人员提供支持,他们会找到另一种解决方案,以完成他们的工作。即使那个解决方案不如利用数据库的方案, 以后也很难删除或优化它。通常情况下,这种解决方案对应用程序的功能,性能,或两者都有长期的影响。

数据库管理系统擅长存储,搜索和转换数据。当DBMS和一个精心设计的数据模型相结合,它们执行这些任务的速度比任何应用程序的方法都要快。这里是一个挑战:一个数据库系统必须要精心设计,才能执行,并在它被置于日益增长的对更多用户或更多数据的需求时继续执行。需要花费时间来设计一个支持这些要求的可扩展的数据库系统。如果在设计过程中走了捷径,那么数据库系统将不能满足性能要求,这通常会导致一个重大的重新设计或硬件开支。这两个选项都表示浪费和低效率:重新设计需要额外的时间和精力,即使硬件能够使系统达到可接受的性能水平,想象一下如果有一个良好的设计和强大的硬件,系统的能力可以强大多少。

这一切听起来很使人沮丧:如果客户不知道他们想要什么,不准确描述他们的流程,并滥用工具以减少他们的工作量,软件开发人员和他们构建的应用程序似乎注定是要失败的。因为你没有一个应用程序和数据最终会变成什么样的完整画面,所以你不能预先创建一个良好的设计,而即使你确实在项目开始时就有关于最终需求的完整和准确的信息,当你和竞争对手的目标是相同的客户群时,你也没有时间进行数据建模和系统设计。然而,如果数据库设计是有缺陷的,那么你的用户将对系统响应时间不满,而你的项目也将被缓慢的响应时间和系统崩溃所困扰。

还有另一种选择。你可以做一些革命性的东西:你可以承认,变化是不可避免的,准备迎接并管理变化。如果你期望变化,或做得更好,鼓励变化,并从中吸取教训,你就开启了创建客户正好需要的应用程序的可能性。如果你观察最终用户如何执行他们的工作,而不是让他们来描述它,你会发现当前流程中的缺点,你也许能轻松去除这些缺点。这给你一个真正的创新机会,你建立了用户需要的,但谁也没有想到的工具。如果你让客户参与建立你的应用程序,在这个过程中更早把新功能交到他们手中,并要求客户反馈,然后使用该反馈,以在开发过程的早期阶段改善应用程序,其结果是一个协作的过程和更好的产品。如果你观察客户使用你构建的工具,你会发现更多的方法来提高你的产品。这被称为迭代设计,我相信这种方式会导致更好的产品,更高的客户满意度,以及为软件开发人员创造更令人满意的工作环境。

数据库和敏捷开发

迭代开发是不是一个新概念:有众多的书籍和专家涉及软件开发和迭代设计。然而,当涉及到数据库时,几乎没有有关如何管理数据库迭代设计的有用信息。同时,越来越多的应用数据库在缺乏充分设计的情况下被匆匆创建。无论是概念设计,逻辑设计或物理设计,一个共同点是,在太多的情况下缺少有目的的设计。这将导致极其常见的最终结果:数据库和应用程序不能如预期那样执行。应用程序可能通过了功能测试要求,但一旦它被置于预期的用户负载下,性能可能要比可接受的差很远。虽然有可能使一个设计不良的应用程序有更好的表现,来建立一个数据库,在不断增长的数据量和并发用户越来越多下将继续如预期那么执行,你必须有一个精心设计的模式。你也许能够通过增加更多的硬件资源来提高性能,但仔细想想。这些硬件资源的哪些部分只是用来补偿一个不好的设计?以及如果不存在设计缺陷,你还可以从你的硬件投资中得到多少好处?当模式有缺陷时,应用程序返工所需的代码量会增加。这产生了一个很大的问题,因为随着时间推移数据库模式保持冻结,而应用程序的功能不断扩大。由于变更请求继续流入而额外的字段被附加到已经有问题的模式设计中,性能问题变得越来越难以修复。

这类问题的最终结果是,架构师和开发人员已经得出结论,解决方案是将尽可能少的功能放到数据库。也许,这是可以理解的:因为他们已经学会把数据库变化视为痛苦的,他们试图通过避免数据库来避免痛苦。他们甚至在数据库中做得最好的任务中避免使用数据库,因为他们害怕他们可能有一天必须去改变它。编写“数据库无关”的程序的愿望增加了问题,因为DBMS中某些最好的特性和功能被闲置了。不幸的且有些讽刺的结果是一个非常昂贵的DBMS被闲置,而很多支工人的队伍正努力重新创建数据库中已有的功能,而那些功能是他们根据其数据库现有许可已购买了的。选择购买一个强大的产品授权,但在设计应用程序时,却仿佛你购买的是最小公分母(译者注:指数据库中最基本的功能),这是开发团队可能犯的代价最高的错误之一。真实的情况是,无论DBMS是Oracle,MySQL,Postgres,或SQL Server,良好的开发人员都很难找到。为什么要花费时间去重建另一家公司已构建好并已购买的功能?如果我们的目标是建立一个具有竞争力的产品,这个产品会满足客户的需要,同时最大限度地提高我们的投资回报,那么就应该充分利用购买的DBMS平台已有的每一个有用的功能。

到目前为止,我已经列举了软件开发项目众多矛盾的目标:你需要快速构建,你需要在有足够的知识之前继续,你需要设计以支持长期的性能目标,以及这些性能目标可能是未知的。如果你还没有一个产品,你怎么能知道有一天,你会吸引多少用户?如果你创造惊人的,创新的东西,你将在一个比你预期短很多的时间内有比你可能想到的更多的用户。然后你的热心用户及时将使系统超负荷,从而导致最新的软件产品在经历一个非常公开的失败的头版故事之一。你需要把稳定性作为目标并通过一个迭代的设计过程鼓励变化。你希望你的系统是透明和使用简单的,使用户能够在每次连接时无需重新学习的步骤而做他们的工作。但你必须承认,你对用户工作的理解可能不准确。考虑到所有潜在的可能使得一个项目无法应付这些挑战的因素,软件项目怎么可能取得成功?你不可能让时光倒流到开发变动不这么快的时代。相反,你必须预想到设计将改变,装备数据库管理员,数据库开发人员和应用程序开发人员,以管理到今天的变化并仍然关注这些变化作为一个整体对系统的长远的影响。