一次小项目的思考

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

胡扯。

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

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