软件中的黑盒子(1)--转一个数据库老师的文字!

   我有一个疑问，是基于第一手的经验而得出的，那就是为什么数据库软件开发会如此频繁地失败。首先澄清一点，这里所说的失败不仅仅是指那些由于失败而不能提供文档的项目，也包括那些开发和部署时间超过计划的项目，因为这些软件还需要经过“再编码”、“再构建”或者“优化”才能算完成。根据我个人的观点，把这些延迟的项目都称为“失败项目”：因为它们不能够按照时间进度表按时（或提前）完成。
导致失败最常见的原因是缺少对数据库的实现知识：缺少对所使用的基础工具的基本理解。“黑盒子”方法本意是要防止开发人员在数据库上犯错误。实际上却在鼓励人们不要学习数据库相关知识。在许多情况下，这就导致避免使用这些相关知识。这种方法的原因看来是与FUD（Fear(害怕)、Uncertainty(不确定)和Doubt(怀疑)）相关的。这些人听说数据库是“难”的，SQL、事务和数据完整性也是“难”的。他们的解决方法就是：不要让任何“难”中。于是，他们把数据库看做是一个黑盒子，让一些软件工具来产生所有代码，相要多层保护措施来避免接触“难”数据库。
这是一种我绝不能不理解的数据库开发方法。我很难理解这种方法的原因之一就是，对我来说，学习Java和C要比学习数据库的概念难得多。现在我能熟练掌握JAVA和C,但我花费了很多时间,才能熟练地掌握数据库并没有花费这么多时间。对于数据库，需要了解它是如何工作的，但是不必知道它的细节。当使用Java和编程的时候，确实需要知道所有的细节，而C和Java是内容很庞大的语言。
另一个原因是，如果正在构建一个数据库应用程序，那么软件中最重要的部分是数据库。一个成功的开发团队将认识这一点并且要让其他人都知道这一点，来共同关注数据库。在我所参与过的许多个项目里，却几乎都是相反的情况。
典型的情况如下：
开发人员受过GUI（图形用户界面）工具或用来构建前端的语言（例如Java）的系统培训。许多情况下，他们进行数周甚至数月的这种培训。
团队没有经过Oracle的培训并且没有使用Oracle的经验。大多数人没有任何数据库的使用经验。
存在不可避免的性能问题，数据库完整性问题，挂起问题等等（尽管有很漂亮的界面）。
构建数据库的应用程序开发人员不用理解数据库的思想使我很惊讶，而且他们的看法很坚决。许多人坚持开发人员来需要接触数据库，不要花时间去掌握数据库，甚至不必知道关于数据库任何事情。为什么？我曾经不止一次地听说过：“……Oracle是世界上最具可伸缩性的数据库,人们不必学习它，它将会做好一切。”确实，Oracle是世界上最具可伸缩性的数据库。然而，在Oracle中编写不不易伸缩的坏代码，要比编写出可伸缩的好代码容易得多。可以用其他技术来代替Oracle,这一点同样也是事实。编写运行差的应用程序比编写运行好的应用程序要容易。有时候，如果不知道自己在做什么，可能容易得不能在世界上最可伸缩的数据库上构建一个单用户系统。数据库是一个工具，在任何工具使用得不恰当都有可能性导致灾难。不恰当地使用工具会导致结果一团糟，由于对数据库的一无所知会产生相似的结果。
最近我在开发一个项目，其中的系统结构设计是非常好的。Web浏览器客户可以通过HTTP连接到运行JSP（javaServerPage）的应用服务器。应用程序的逻辑完全是由工具产生的，并且作为EJB来实现（用容器管理持久性），以及物理上位于另一台应用服务器。数据库只包含表和索引没有其他的。
假设我们从一个技术复杂的体系开始：有4个必须相互通信的实体：Web浏览器到应用服务器上的JSP，再到EJB和数据库。这就需要技术过硬的人来开发、测试、优化和部署这些应用程序。我们对应用程序的后期开发进行基准测试。要知道的第一件事就是他们访问数据库的方法：
感觉到难点是什么，争论的焦点是什么？
认为需要克服的主要障碍是什么？
大家没有想法。当被问到：“好，当需要优化一个生成的查询时，谁能帮助我重与EJB中的代码？”时，他们的回答是“哦，您不能优化那些代码，所有这些必须在数据库中完成。”这个应用程序就被搁置没人理睬了。那时，我就准备从这个项目脱手，对我来说已经很清楚了，这个应用程序根本不能用：
构建应用程序时对数据库级的伸缩没有一点考虑。
应用程序本身不能被优化或不涉及应用程序。
大多程序员编程经验，是80~90%的优化工作是在应用级完成的，而不是在数据库级完成的。（待续）