一次小项目的思考

最近的一个项目，四个开发人员，大概做了一个月多一点，从需求，到最终代码的完成。
写思考，我想，主要还是要回顾一下在项目中遇到的问题，或是有什么比较好的经验，新的体会值得记录下来，以供以后参考。在这里，主要是要思考两个方面的问题，数据库和测试。
1. 数据库
   对于数据库，在j道上面有这样一篇文章《数据库已死》，其主要思想，个人感觉，主要还是对象与关系的问题，我们现在的主流已经是面向对象，但现在，可能很多公司仍以数据库建模作为其一条主线，首先进行数据建模，erwin，powerdesigner，然后创建相应的表，下面，就使用myeclipse,hibernate tools等生成相应的实体类，以及相应的映射文件。包括以前的几个项目，者是在开始花了大量的时间进行数据库的设计，中途加入的项目，也会在进入项目组的开始阶段让你熟悉其数据库的表结构，当面对大量的表的时候，看着E-R图上面的“蜘蛛网”的时候，可能，就已经晕了。
实际上，在面向对象的时代，数据库只是状态持久化的一种手段，数据库的表结构完全可以通过Hibernate等ORM工具自动生成。
在这个小项目中，前期，并没有花大多的时候在数据库的设计上，在初期建模了一些核心对象，创建相应的实体类，加上相应的注解，借助于hibernate的hbm2ddl，完全可以由hibernate自动生成相应的表结构。当增加新的对象的时候，也只需要定义其类结构。
并且，可以提供不同的sessionfactory，分别针对测试等环境，也可以做到一定程度的database migration。
2. 测试
   TDD，BDD，持续集成~~~~等等，不知道有多少公司实施了，并且实施的情况如何。在以前的项目中，最怕的，就是测试数据依赖于其它的模块，当跑一次测试，还需要去跑一下由其它小组开发的模块，当对该模块的业务不太了解的时候，测试起来，还是比较麻烦的，还有可能需要麻烦其它小组的人员来为我们提供相应的测试数据。
这种情况，其中一个原因，测试代码太少。所以在这个项目中，针对一些核心的，或是较复杂的业务逻辑，都提供了相应的测试代码(当然，这里有一个粒度的问题)，虽然在开发过程中，需要抽出一部分时间来编写相应的测试代码，但在实际过程中，效果还是比较明显的。

评论

116 楼 TheMarine 2009-08-25  

但是我们使用缓存,为什么非得在1秒内执行完呢?

115 楼 ray_linn 2009-08-25  

TheMarine 写道

ray_linn 写道

TheMarine 写道

metadmin 写道

我们对系统进行分析后，采取了缓存、临时表两种手段，极大降低调用数据库次数，提高每次调用效率。这两种方式，对系统性能提升非常大。上月数据只要1天时间就能处理完毕。

只要稍微合理利用数据库，同时对自己的程序进行优化。显然数据库还是好的方式！！

你所说的不正好证明了数据库是缺乏弹性的,数据库是有极限的,把负载全部丢在数据库端,全部依赖数据库性能解决业务复杂度就是你遇到的问题,也是现在普遍的,如果负载继续增加呢?单机数据库会撑不住的,弹性就是在增加集群服务器的时候性能随之明显提升,当然数据库集群也是可以的,但是相比app集群的代价呢?
拜托大家都真正去理解一下"数据库已死"的真实含义之后再来说吧,数据库是一定要也一定会使用的,但是把设计重心移到业务上,利用集群,缓存减轻数据库负载才是他说的意思.

胡扯。

假如一秒钟里有1万次insert,1万次select，而且这些数据调用都是必须的，看不出你的app集群有什么用处，而且只会更慢，因为数据库不单单要处理这么多次SQL，而且还要parser这么多次SQL.

减少数据库调用的有效方法之一，客户端可以用缓存，服务器端可以用临时表，游标，缓存等等方法。app集群根本不能减轻数据库调用的压力，2万条SQL调用分配到10个app集群上，数据库端收到的还是2万条SQL.

应该没有人会认为app集群会使得数据库总操作减少.我的意思可能没有表达明白,我是说,当你把负载集中到服务器,操作缓存,尽可能的减少数据库操作次数的前提下,使用app集群可以显著提高性能.同时你既然说集群没用,那么也等于说,系统性能的瓶颈在数据库端了.而我们要解决的就是让数据库解放出来,不要单单的承受那么大的压力,因为它的弹性比app来的小.

作为讨论前提，我们先假设采用APP和采用SP的SQL语句长度接近，那么采用APP和采用SP有什么区别呢？

a. 采用APP，SQL语句被发送至服务器端，服务器端Parser该SQL语言编译SQL，执行后（可被缓存）之后返回值。
b. 采用SP, SQL语句直接执行后返回值。

由于每秒被发送至服务器的SQL语句相同，根据<Oracle高级编程>一书，a 要比 b 慢上20倍，对于相同的SQL的总量，a 要比 b慢上许多，对数据库的CPU更是折磨。

114 楼 rainlife 2009-08-25  

ray_linn 写道

TheMarine 写道

metadmin 写道

我们对系统进行分析后，采取了缓存、临时表两种手段，极大降低调用数据库次数，提高每次调用效率。这两种方式，对系统性能提升非常大。上月数据只要1天时间就能处理完毕。

只要稍微合理利用数据库，同时对自己的程序进行优化。显然数据库还是好的方式！！

你所说的不正好证明了数据库是缺乏弹性的,数据库是有极限的,把负载全部丢在数据库端,全部依赖数据库性能解决业务复杂度就是你遇到的问题,也是现在普遍的,如果负载继续增加呢?单机数据库会撑不住的,弹性就是在增加集群服务器的时候性能随之明显提升,当然数据库集群也是可以的,但是相比app集群的代价呢?
拜托大家都真正去理解一下"数据库已死"的真实含义之后再来说吧,数据库是一定要也一定会使用的,但是把设计重心移到业务上,利用集群,缓存减轻数据库负载才是他说的意思.

胡扯。
假如一秒钟里有1万次insert,1万次select，而且这些数据调用都是必须的，看不出你的app集群有什么用处，而且只会更慢，因为数据库不单单要处理这么多次SQL，而且还要parser这么多次SQL.

减少数据库调用的有效方法之一，客户端可以用缓存，服务器端可以用临时表，游标，缓存等等方法。app集群根本不能减轻数据库调用的压力，2万条SQL调用分配到10个app集群上，数据库端收到的还是2万条SQL.

将2万次操作，分散到10台app，是否会令db减轻压力，这个，是否有相应经验的人谈一谈。
另外，采用app集群等方式，通过缓存等手段，或分散SQL的操作，或者根本就是在缓存中来取数据，来减轻对db的操作。

113 楼 daquan198163 2009-08-25  

logicgate 写道

tianhaoleng 写道

楼上的说法正好证明了：以数据库为中心的编程方式，最终是极难扩展的。

倘若我把逻辑采用java对象表达，自然就减少的对数据库的依赖。

原本要执行2万条SQL，可能现在只需要执行几条获取数据的SQL就能够完成原先的业务。

ORM, object最终还是要map到relational database,我不知道你两万条sql怎么减到几条获取数据的SQL

对于很多OLTP类型的系统，hibernate, EJB-QL之类的根本是无法胜任的。这种情况下从性能方面考虑，只能以数据库为中心。

OLAP？

112 楼 TheMarine 2009-08-25  

ray_linn 写道

TheMarine 写道

metadmin 写道

我们对系统进行分析后，采取了缓存、临时表两种手段，极大降低调用数据库次数，提高每次调用效率。这两种方式，对系统性能提升非常大。上月数据只要1天时间就能处理完毕。

只要稍微合理利用数据库，同时对自己的程序进行优化。显然数据库还是好的方式！！

你所说的不正好证明了数据库是缺乏弹性的,数据库是有极限的,把负载全部丢在数据库端,全部依赖数据库性能解决业务复杂度就是你遇到的问题,也是现在普遍的,如果负载继续增加呢?单机数据库会撑不住的,弹性就是在增加集群服务器的时候性能随之明显提升,当然数据库集群也是可以的,但是相比app集群的代价呢?
拜托大家都真正去理解一下"数据库已死"的真实含义之后再来说吧,数据库是一定要也一定会使用的,但是把设计重心移到业务上,利用集群,缓存减轻数据库负载才是他说的意思.

胡扯。

假如一秒钟里有1万次insert,1万次select，而且这些数据调用都是必须的，看不出你的app集群有什么用处，而且只会更慢，因为数据库不单单要处理这么多次SQL，而且还要parser这么多次SQL.

减少数据库调用的有效方法之一，客户端可以用缓存，服务器端可以用临时表，游标，缓存等等方法。app集群根本不能减轻数据库调用的压力，2万条SQL调用分配到10个app集群上，数据库端收到的还是2万条SQL.

应该没有人会认为app集群会使得数据库总操作减少.我的意思可能没有表达明白,我是说,当你把负载集中到服务器,操作缓存,尽可能的减少数据库操作次数的前提下,使用app集群可以显著提高性能.同时你既然说集群没用,那么也等于说,系统性能的瓶颈在数据库端了.而我们要解决的就是让数据库解放出来,不要单单的承受那么大的压力,因为它的弹性比app来的小.

111 楼 logicgate 2009-08-25  

tianhaoleng 写道

楼上的说法正好证明了：以数据库为中心的编程方式，最终是极难扩展的。

倘若我把逻辑采用java对象表达，自然就减少的对数据库的依赖。

原本要执行2万条SQL，可能现在只需要执行几条获取数据的SQL就能够完成原先的业务。

ORM, object最终还是要map到relational database,我不知道你两万条sql怎么减到几条获取数据的SQL

对于很多OLTP类型的系统，hibernate, EJB-QL之类的根本是无法胜任的。这种情况下从性能方面考虑，只能以数据库为中心。

110 楼 tianhaoleng 2009-08-25  

楼上的说法正好证明了：以数据库为中心的编程方式，最终是极难扩展的。

倘若我把逻辑采用java对象表达，自然就减少的对数据库的依赖。

原本要执行2万条SQL，可能现在只需要执行几条获取数据的SQL就能够完成原先的业务。

109 楼 ray_linn 2009-08-25  

TheMarine 写道

metadmin 写道

我们对系统进行分析后，采取了缓存、临时表两种手段，极大降低调用数据库次数，提高每次调用效率。这两种方式，对系统性能提升非常大。上月数据只要1天时间就能处理完毕。

只要稍微合理利用数据库，同时对自己的程序进行优化。显然数据库还是好的方式！！

你所说的不正好证明了数据库是缺乏弹性的,数据库是有极限的,把负载全部丢在数据库端,全部依赖数据库性能解决业务复杂度就是你遇到的问题,也是现在普遍的,如果负载继续增加呢?单机数据库会撑不住的,弹性就是在增加集群服务器的时候性能随之明显提升,当然数据库集群也是可以的,但是相比app集群的代价呢?
拜托大家都真正去理解一下"数据库已死"的真实含义之后再来说吧,数据库是一定要也一定会使用的,但是把设计重心移到业务上,利用集群,缓存减轻数据库负载才是他说的意思.

胡扯。

假如一秒钟里有1万次insert,1万次select，而且这些数据调用都是必须的，看不出你的app集群有什么用处，而且只会更慢，因为数据库不单单要处理这么多次SQL，而且还要parser这么多次SQL.

减少数据库调用的有效方法之一，客户端可以用缓存，服务器端可以用临时表，游标，缓存等等方法。app集群根本不能减轻数据库调用的压力，2万条SQL调用分配到10个app集群上，数据库端收到的还是2万条SQL.

108 楼 rainlife 2009-08-25  

metadmin 写道

我们对系统进行分析后，采取了缓存、临时表两种手段，极大降低调用数据库次数，提高每次调用效率。

正是因为太过依赖于数据库，而造成了相应的瓶颈问题。

107 楼 TheMarine 2009-08-25  

metadmin 写道

我们对系统进行分析后，采取了缓存、临时表两种手段，极大降低调用数据库次数，提高每次调用效率。这两种方式，对系统性能提升非常大。上月数据只要1天时间就能处理完毕。

只要稍微合理利用数据库，同时对自己的程序进行优化。显然数据库还是好的方式！！

你所说的不正好证明了数据库是缺乏弹性的,数据库是有极限的,把负载全部丢在数据库端,全部依赖数据库性能解决业务复杂度就是你遇到的问题,也是现在普遍的,如果负载继续增加呢?单机数据库会撑不住的,弹性就是在增加集群服务器的时候性能随之明显提升,当然数据库集群也是可以的,但是相比app集群的代价呢?
拜托大家都真正去理解一下"数据库已死"的真实含义之后再来说吧,数据库是一定要也一定会使用的,但是把设计重心移到业务上,利用集群,缓存减轻数据库负载才是他说的意思.

106 楼 lovejuan1314 2009-08-25  

metadmin 写道

呵呵，数据总是要持久化保存的。目前最好的方案是数据库。将来是否会出现其他中间件来代替，不好说。。。。

但，目前很多系统出现瓶颈，就埋怨数据库。这显然不对。

在系统运行不流畅的时候，我们使用sql命令对数据库操作，处理速度还是非常好的。这在某种层次上面，说明了数据库坚如磐石。瓶颈是在应用层面，也就是我们的业务系统。

就举个案例吧：
有好几年了，我们使用JAVA给某银行做数据分析系统，全部使用JAVA语言编写的，没有使用存储过程。头几个月运行效果不错，随着数据量上升，系统几乎是死翘翘了。
在快死翘翘的时候，我计算了一下如果把上月数据分析完毕需要100年时间。记得当时又快过年了。情况还是比较着急的，组员也急着回家。

我们对系统进行分析后，采取了缓存、临时表两种手段，极大降低调用数据库次数，提高每次调用效率。这两种方式，对系统性能提升非常大。上月数据只要1天时间就能处理完毕。

只要稍微合理利用数据库，同时对自己的程序进行优化。显然数据库还是好的方式！！

如果不合理使用数据库，数据库会被一些蠢货玩死。

同意,我也实际遇见过一个真实的案例,负责开发的coder在程序中对数据库一个blob的字段读取操作不当,将当时维护的一台AIX小型机直接down掉...

105 楼 metadmin 2009-08-25  

呵呵，数据总是要持久化保存的。目前最好的方案是数据库。将来是否会出现其他中间件来代替，不好说。。。。

但，目前很多系统出现瓶颈，就埋怨数据库。这显然不对。

在系统运行不流畅的时候，我们使用sql命令对数据库操作，处理速度还是非常好的。这在某种层次上面，说明了数据库坚如磐石。瓶颈是在应用层面，也就是我们的业务系统。

就举个案例吧：
有好几年了，我们使用JAVA给某银行做数据分析系统，全部使用JAVA语言编写的，没有使用存储过程。头几个月运行效果不错，随着数据量上升，系统几乎是死翘翘了。
在快死翘翘的时候，我计算了一下如果把上月数据分析完毕需要100年时间。记得当时又快过年了。情况还是比较着急的，组员也急着回家。

我们对系统进行分析后，采取了缓存、临时表两种手段，极大降低调用数据库次数，提高每次调用效率。这两种方式，对系统性能提升非常大。上月数据只要1天时间就能处理完毕。

只要稍微合理利用数据库，同时对自己的程序进行优化。显然数据库还是好的方式！！

如果不合理使用数据库，数据库会被一些蠢货玩死。

104 楼 everlasting_188 2009-08-25  

lovejuan1314 写道

Oracle expert tom kyte 的开发经验
恩,确实如此..  因为数据库中已经存在了诸多的解决方案,而数据库却又是最接近底层东西,所以,能在数据库完成的尽量在数据库完成这是性能优化的一方面. 当然,如果考虑系统的移植性,就需要考虑避免使用它来完成过多的东西了..

性能和可移植性永远是个三角,看你的重心在什么地方. 如果你重心在产品的移植性,那就会必然会牺牲部分性能. 如果重在性能势必会影响一些产品的可移植性.

层次性的数据库早期出现过，现在也有，从查找的角度来说，更接近与人的思维方式，但是现在不是主流。关系型数据库，有一整套理论，计算机从本身上说智能化程度不高(人工智能我们还没有特别牛的理论上的突破)，你要想把处理速度提上去，你需要按照他的工作方式来设计。

现实社会的复杂的，人的行为也是复杂，这样就导致了有些行为很难翻译成计算机的语言来做，这也是为什么硬件发展快，软件发展慢的原因。


设想你设计一个程序，很OO，可移植性强，一普通机器上可以支持10个并发用户；另外一个不太OO的程序，一普通机器上可以支持1000个并发用户。对小项目来说，会选择前者，对大的项目和平台来说选择后者。


还在冯诺依曼的体系结构下，绝对的OO很难，如果本身底层就是一个OO的东西，上层不得不OO，但是现实情况不是。


OO只是理解世界的一种方法，不是外能的，像哲学上的唯心和唯物，说不清楚谁对谁错。就事论事，选择好的解决方案解决问题才是王道。

那里有什么万能的设计方法学，没看到，可能我理解能力有限吧。

103 楼 coolnight 2009-08-25  

ray_linn 写道

lovejuan1314 写道

恩,确实如此..  因为数据库中已经存在了诸多的解决方案,而数据库却又是最接近底层东西,所以,能在数据库完成的尽量在数据库完成这是性能优化的一方面. 当然,如果考虑系统的移植性,就需要考虑避免使用它来完成过多的东西了..

性能和可移植性永远是个三角,看你的重心在什么地方. 如果你重心在产品的移植性,那就会必然会牺牲部分性能. 如果重在性能势必会影响一些产品的可移植性.

最后一段话说得相当辩证，当浮一大白

P， 两个点， 怎么成三角， 跷跷板还差不多

102 楼 sulins 2009-08-24  

才一次“小项目”而已，楼主就能得出这么大的结论。
呵呵，楼主真“牛”。

101 楼 ray_linn 2009-08-24  

lovejuan1314 写道

恩,确实如此..  因为数据库中已经存在了诸多的解决方案,而数据库却又是最接近底层东西,所以,能在数据库完成的尽量在数据库完成这是性能优化的一方面. 当然,如果考虑系统的移植性,就需要考虑避免使用它来完成过多的东西了..

性能和可移植性永远是个三角,看你的重心在什么地方. 如果你重心在产品的移植性,那就会必然会牺牲部分性能. 如果重在性能势必会影响一些产品的可移植性.

最后一段话说得相当辩证，当浮一大白

100 楼 lovejuan1314 2009-08-24  

ray_linn 写道

lovejuan1314 写道

Oracle expert tom kyte 的开发经验

对于开发数据库软件，我有一套很简单的哲学，这是我多年以来一直信守的思想：
  如果可能，尽量利用一条 SQL 语句完成工作。
  如果无法用一条 SQL 语句完成，就通过 PL/SQL 实现（不过，尽可能少用 PL/SQL！）。
  如果在 PL/SQL 中也无法做到（因为它缺少一些特性，如列出目录中的文件），可以试试使用
Java 存储过程来实现。不过，有了 Oracle9i 及以上版本后，如今需要这样做的可能性极小。
  如果用 Java 还办不到，那就在 C 外部过程中实现。如果速度要求很高，或者要使用采用 C
编写的一个第三方 API，就常常使用这种做法。
  如果在 C 外部例程中还无法实现，你就该好好想想有没有必要做这个工作了。

呵呵 Tom <Oralce 高级编程> ，其观点就是，花在数据库上的每一分钱都应该得到回报，有一项功能不用，就是浪费。

恩,确实如此..  因为数据库中已经存在了诸多的解决方案,而数据库却又是最接近底层东西,所以,能在数据库完成的尽量在数据库完成这是性能优化的一方面. 当然,如果考虑系统的移植性,就需要考虑避免使用它来完成过多的东西了..

性能和可移植性永远是个三角,看你的重心在什么地方. 如果你重心在产品的移植性,那就会必然会牺牲部分性能. 如果重在性能势必会影响一些产品的可移植性.

99 楼 java_mike 2009-08-24  

我也比较赞同楼主的观点。 

98 楼 hsbljyy 2009-08-24  

conrol 写道

一直有个疑问，是用hibernate自动创建表还是用powerdesign等建模工具建表？

虽然我很少使用Hibernate，不过，如果我用Hibernate的话，我会用Hibernate自己创建。

97 楼 conrol 2009-08-24  

一直有个疑问，是用hibernate自动创建表还是用powerdesign等建模工具建表？