数据是处理的目标，db或者OO是处理的手段，那种方法主要看客户需求。软件开发的第一要务是满足用户需求，否则就是在空谈。
看了这么多，个人觉得大家说的都有道理，但是banq说的更是大势所趋。
我们现在用的都是关系型的数据库,他主要解决的是结构数据的存储,早期的信息化建设是从信息有序的存储到对联机交易(数据的快速访问)的支持,这里关系型的数据库都发挥了很大的作用,在这个方面关系型数据库还会继续发挥他的作用.
目前信息化的要求是对数据的利用,如对海量数据的分析,信息的检索(大部分是针对非结构化数据的检索),这些都不在是传统的数据库技术能很好解决的问题,新技术出现是很正常的.
传统的数据库有他自己的应用场景,他解决的是结构数据存储和访问的问题,并不能很好的解决数据的处理问题.
我现在在实际的应用中已经感觉到数据库系统提供的功能已经不能很好的满足数据检索的要求,即使是对结构化数据的检索.必须有更先进的技术去解决这些问题如:分布式处理、并行处理和网格计算等更为灵活的手段.
数据存储和数据处理的技术分离这个肯定是必然的趋势.
[该贴被UBOSJQ于2008-10-06 21:10修改过]
数据是处理的目标，db或者OO是处理的手段，那种方法主要看客户需求。软件开发的第一要务是满足用户需求，否则就是在空谈。
这个很不赞成,客户提的都是业务需求,具体点都是业务功能,会关心你用面对对象,还是过程,他只要结果.
再说db和oo都不是一个层次的东西.
楼上经验之谈很值得大家借鉴。
其实国外从2001 2003就提出JavaEE集群让数据库休息喘气的概念，翻出本站2003年贴：
趋势和现实还是有差距的，我们在现实中更看重的需求
我也不诋毁oo，但总感觉把简单的问题复杂化了，尤其是erp这种以数据为中心的系统
现在企业erp还是停留在局域网范围内，小数据量能放到网络中，操作者仅限于员工，所以基于数据库还是暂时几年内还是无法替代的。
现在互联网发展是很快，方向也很多。但让企业去用企业还是趋向与成熟度比较高的。
>总感觉把简单的问题复杂化了
这其实是从不同角度，我从A角度看认为很简单，你习惯从B角度看当然认为复杂，这也就是我在“孔子智慧和学习方法”中提到，如果你习惯一种方法论，可能就认为其他方法来很不顺，很别扭。
http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=34743&message=23117579#23117579
楼上可以反过来考虑这样一个情况：OO可能非常符合日常生活思考，是最自然简单了，因为你习惯数学数据思维，而OO和数据库思维是矛盾的，是mismatch的，所以，你可能觉得OO将简单问题复杂化。
不论哪个方法，衡量方法的好坏在于，谁能够更精确反映需求，谁能够快速跟随需求变化，谁能使做出来的软件更容易维护，更容易拓展，现在事实已经证明：OO方法论要好些。
TO BANQ
我觉得很多时候大家都把问题复杂化了，其实OO 和 db 并不是同一个层面上的。我很赞同程序需要OO，需要变得和我们现实世界一样简单。打个比方，数据库就好像仓库，用来存东西，而JAVA执行计算功能,这就好像现实中的各种机构或者人，需要从仓库里拿东西，处理一些事务，然后把新的东西存进去。大家执行的只是不同的功能，而随着数据库的JAVA的发展，现在数据库本身能够进行一些计算，而JAVA似乎也能开发出一些存储功能。BANQ似乎在说，好吧，以后不要仓库了，现在人力便宜，我们每个人都24*7捧着我们的东西，省得放进去还麻烦。首先我承认这样是可行的，而且省却了从数据库拿data的过程，但这会带来更多的问题：
1. 人力肯定是比仓库要贵的。
2. 其次仓库有大有小，小的好说，我目前所在公司data有70T,全部存在5台IBM AIX上面，我无法估计如果用缓存如何处理。
3. 数据库本身提供很多功能：权限，索引，锁，SQL,backup,health check。而且很多功能都既能细化到每一行data,又能大到整个database。比如权限，甚至可以只给一行data的权限。也许你可以说这些JAVA都可以做到，但是如此将这么多繁琐的功能分散各个物件之后，使得每一个新的项目都将要耗费大量的精力（遵照banq的具体项目要具体分析，每个项目都是不同的）成本远高于买一个database.
4. 说数据库无法扩展，集群，这是很幼稚的。现在的Database和任何应用服务器一样，扩展非常简单，直接加服务器就可以了。现在database最重要的功能就是DPF(DATABASE PARTITION FEATURE) ,能够将database分布到无限台SERVER上面。
5 其实从更高的角度来看，database也不过是一个object而已，他有他自身的功能，sql 就好像它的API.只是在有些人眼里，他有了一些它不该拥有的功能。
以上我觉得数据库已死这个观念是否太过随意？
非常愿意和楼上这样有理有节的讨论，在讨论中我也受益匪浅。
有几点我要反复重申一下，以消除沟通上的误区：
1.人力肯定是比仓库要贵的，这个观点不认同，不是你的贵的含义是什么？硬件还是软件，硬件上现在普通PC和内存非常便宜，软件上，对象最自然的生存环境就是内存，只要你构造创建一个对象，默认首先是在内存中。
另外就是有其他理由贵，那么我想，软件设计质量是第一位的，软件的拓展性维护性是第一的，否则，如果一个软件没有很好的拓展性，就是请比尔盖兹来都没有办法。为软件质量任何牺牲都是值得的。
2.数据库本身提供很多功能：权限，索引，锁。这些功能都可以围绕对象在内存中实现，而且性能更好。你认为“将这么多繁琐的功能分散各个物件”是高成本的，这个我不认可，这是因为从数据思维看，比较复杂，其实，用OO分析设计，有那么多设计智慧，不会琐碎到每个数据。
数据就相当于知识，而OO则相当于方法论，这相当于运输工具和运输货物，只要我们设计好运输工具，就可以运输无穷无尽的货物。数据和知识可以无穷无尽，但是方法论则没有那么复杂，所以，我们不能看到有那么多数据，就认为软件会很复杂，这忽视了软件设计方法论的存在。
另外，为了设计一个高质量有生命的软件，可以跟随你的企业成长而迅速成长，而不是你一年内企业成长3倍，企业软件要滞后很长时间才能跟随，那么很显然，企业软件成为企业成长的绊脚石和瓶颈，这些都是让我们必须以更高成本和投入软件设计的原因，这些都是值得的。
3. 数据库无法扩展，集群，这我没有说过，我说数据库可以集群，但是有限，这里面同样存在一个精确制导问题，我们使用Bean集群SOA，可以对某个繁忙的服务功能进行精确集群，其他无需集群的则不用，这种针对业务Bean的集群只有用应用程序JavaEE才能实现，因为没有一个通用产品能够预先知道将来它的将来主要负载在哪个业务功能上，因为业务功能是每个项目每个项目实现的，这就是精确制导。
云计算已经将数据处理和数据存储分离，使用数据库就是将数据处理和存储混同在一起，这种打包式的解决方案是比较简单，就像我们如果不讲OO，完全可以按照计算机执行顺序来编写面向过程的程序，也感觉简单，不用谈什么松耦合，不用谈什么分离，那么这个软件就是僵硬一块，没有拓展，更无从维护。
我来总结一下，为什么我认为数据库死了这个结论不是随意的：
1.数据库已经从软件的分析设计领域去除，在整个OOA/OOD/OOP软件生产过程中，我们可以完全不涉及到数据库，也就是在软件的生产领域可以去除数据库。
2.在软件的性能设计上，数据库也是最不可伸缩的，我们可以用Bean集群/SOA和云计算来替代数据库，所以，数据库在软件性能设计领域也可以去除了。
3.在软件的运行环节上，数据库在大量负载访问下，经常死机，第二天醒来你就会发现数据库当机了，这是发生大部分现实生活中的案例，对于这样一个你那么信赖的数据库也会发生背叛 罢工你的事情，你是否只能在数据库厂商高傲的服务态度下，承认自己水平的低下，不是数据库不行，是自己无能？如果我告诉你，使用OO+OO软件平台就可以让你当家作主，你难道一点不动心？实践证明：数据库已经在软件运行环节力不从心了，无法胜任当今开放WEB潮流。
从企业软件应用以上三点我们都可以消灭数据库，就象消灭操作系统一样，那么不宣布其在企业软件应用上的死刑，这样一个直接简单的推论结果就不敢下？哥白尼当初可以在宗教疯狂阻击下呼唤太阳为中心，那么今天21世纪，日益开明和开放的今天，我们就不能说：数据库死了？
非常感谢banq的回复,收益匪浅.
> 1.人力肯定是比仓库要贵的，这个观点不认同，不是你的贵的含义是什么？硬件还是软件，硬件上现在普通PC和内存非常便宜，软件上，对象最自然的生存环境就是内存，只要你构造创建一个对象，默认首先是在内存中。
我的意思是用内存的成本比较高:
1.价格上来讲,内存价格是一直在下降,但是其实硬盘以及数据库的价格也在下降,但同时我们的数据量也在不停的膨胀,总体成本并没有太多变化.而同时内存必然要比硬盘贵.
2.安全性上来说,数据库的安全性必然比直接使用内存存储数据来得高,或许你另外做一些安全措施来保护你的data,但这样同样会增加成本以及降低performance.
> 2.数据库本身提供很多功能：权限，索引，锁。这些功能都可以围绕对象在内存中实现，而且性能更好。你认为“将这么多繁琐的功能分散各个物件”是高成本的，这个我不认可，这是因为从数据思维看，比较复杂，其实，用OO分析设计，有那么多设计智慧，不会琐碎到每个数据。.....
我所说的复杂并不是看到琐碎的数据,而是看到database强大的功能.好比说现在我们不但有一个仓库,还有了一个聪明的仓库管理员.而当我们摒弃这个仓库同时又不想让原来的功能缺失的话,我们只能将原来仓库管理员的任务分配到每个对象身上.但其实在每个不同的project中,我们的对象千差万别,这样我们需要每次都重新来过.
> 3. 数据库无法扩展，集群，这我没有说过，我说数据库可以集群，但是有限......
数据库集群的特点在于,只要你data partition做的漂亮,他可以将非常好将工作分配给每一个CPU,而我觉得集群是否效率高关键在于work balance做的是否好,是否能够保证CPU UTILIZATION的最合理化.而数据库恰恰能够完成这一点.
> 4. 云计算已经将数据处理和数据存储分离，使用数据库就是将数据处理和存储混同在一起.....
首先我也比较赞成
将数据处理和数据存储分离,但我并不认为数据库在于数据处理和存储混同在一起,数据库最大的意义还是在于其存储以及管理数据的能力.数据库和将数据直接存在硬盘上区别在于:
i. 数据库能够更条理的存放数据,这正如仓库区别于空地,它可以更合理的分类.
ii. 同时数据库能够更快更方便地将data提供给使用者以及更方便的管理数据库的权限,这正如仓库还配有一个管理员,他能帮你使得你找货物更快,更便捷,同时能够给与不用使用者以不同的权限.
iii. 数据库有着强大的backup功能,这就好比这个仓库还买了保险,比直接存于硬盘上方便的多.
而目前数据库也有些处理数据的能力,但我认为在一个好的设计中,不应该将其让数据库来完成,这会带来混乱,以及以后软件升级不必要得麻烦.
以下是个人最后的拙见：
当前数据库存在的意义依然如它诞生时一般：优化数据存储,取出，保证数据的安全性以及赋予数据如文件一般的权限设置。而我认为一个好软件应当满足下面3个条件，缺一不可：
1.软件本身框架拓展性高，数据处理performance好。（仅指数据处理能力，不涉及提取数据）
2.数据库存储结构合理，便于提取数据以及提取数据效率高效。
3.软件应用层与数据库沟通良好，这里主要指提取数据的sql写的漂亮。
所以我认为好的软件设计中，应当将application design和database design分开，各自有成熟的团队，同时互相之间的沟通良好。而其中application design为上层，database design为下层，下层要根据上层的request来做design.任何一层的design短板或者沟通欠缺都会成为限制软件的条件，就好像造房子，应用层如房身，database如地基，缺一不可。
如上database真的已死？
我基本明白你的意思，我也尊重你的经验和思维，已经在数据库上钻研很深或拥有一套经验，那么在他眼里DB就不会死。
这里面还是有思维习惯，我认为数据库已死的理由已经在上面帖子中在软件各个环节都说明了，在我们这样一个JavaEE新的思路下，数据库重要性就大幅度下降，从我们这个角度看，数据库沦为操作系统，从我们OO程序员眼中“消失死去”。
所以，我们两个角度不一样，横看成岭，侧成峰。因为现在世界上很多实践下来发现，JavaEE倡导的计算和存储分离，云计算为中心是一个趋势，说句不好听的话：如果没有 JavaEE，现在世界上大部分企业软件都可以使用纯数据库完成，那么厚重的多层架构JavaEE冒出来，位置在哪里呢？比如一个科里就一个科长，如果上面又派一个科长来，那么谁做呢？这就是我说的一山不容二虎，因为JavaEE和关系DB都可以完成企业业务应用，大家在抢夺同一个业务需求，那么必然有所侧重。
如果还是侧重关系数据库，那么javaEE就作为附属，很显然那么多JavaEE架构就没有用；还不如用PHP/Ruby呢。所以，我们要侧重JavaEE这样平台，就需要告诉初学者，没有数据库包袱，他们做JavaEE/OO可能会更好，更容易。
而象你这样有丰富关系数据库经验，再让你转变，就很难，你的经验还是有相当价值，Oracle还是世界第二大软件厂商，虽然他们在向JavaEE转变，但是数据库依然是他的拿手啊。
其实看了下争论这么久，也基本能理解老师的论点，并非数据库目前对我们没用，只是相对于以前的系统（包括设计、开发），数据库在现在系统中的作用越来越小了，不像以前那样是基于先设计数据库的开发。毕竟一个系统的核心在于业务，所以老师是在强化OO而微化DB，当然不是说ＤＢ就没用了，至少目前是！
就像：>>传统的数据库有他自己的应用场景,他解决的是结构数据存储和访问的问题,并不能很好的解决数据的处理问题.
哈哈 加入了一个星期 在这里看了不少贴了
总之还不错。。 学到了不少东西
我觉得像这样的争论，也蛮好玩的。
banq的观点有一定道理，但太偏激了，就像信奉伊斯兰教其实很好，但像塔利班那样就。。。（哈哈，比喻有点偏激）
不过banq也确实是牛人 总之 某些观点看看可以 你就不要当真的 什么事情都没那么绝对 某个公司做某个项目用什么架构 都不是一个简单性能问题能决定的 从客户到老板到架构师 错综复杂各种原因 不亚于探讨“活着的意义”这个古老的话题 认真听取别人的观点 然后自己心中要像明镜一样 就不怕了 。。。。
[该贴被freepig于2008-10-18 17:44修改过]
并不是所有的应用都适合使用云计算的。
1. 云计算的代价/成本，估计能用得起云计算的并不是多数
2. 云计算的风险，数据库有崩溃的风险，不知道云计算有没有停机的风险，又是如何防范解决的。
3. 云计算的性能,google的使用并不能证明云计算适合所有的应用。应用类型是多种多样的
云计算成为现实
本文介绍几个成熟的云计算解决方案，希望更多人抛弃数据库计算模型思想，转向可伸缩的新架构思维。
不要以为云计算很遥远，很昂贵，就在眼前，全部是开源免费，在当前经济危机，到处压缩成本的大趋势下，你还有什么理由不使用开源？
>不知道云计算有没有停机的风险，又是如何防范解决的
云计算通过单点风险来防范，可具体研究集群或云计算技术