楼上这么说说明在大学的课程没有学好？
我记得从传统的瀑布式的设计只有到了详细设计的时候才会出现数据库的概念，而在这之前的需求调研、分析，以及概要设计里面都没有应该没有数据库的。

其实道理很简单，数据库要花钱的，所以很有风险。
如果很晚才确定数据库，可能客户出不起钱，什么就都白做了。

>>>其实道理很简单，数据库要花钱的，所以很有风险。
>>>如果很晚才确定数据库，可能客户出不起钱，什么就都白做了。
一个数据处理应用，花在开发上的钱是小头，花在数据上的钱是大头。
花在数据上的钱，大头不是买数据库，而是花在数据采集上。
与数据比起来，OO只是零头。
既然事实如此，我们在做设计时，不围绕着数据做文章，不是自找麻烦嘛？
没办法，只好委屈OO了。

我不了解您说的数据处理应用是什么样的。
我说说我们公司的应用吧，我们公司的产品是数据挖掘的产品。
数据采集方面的工作是我们通过程序把客户那边的文件导入到我们的数据库中的，由于不同客户文件格式不同，所以应用工程师会写不同的脚本给客户，方便他们导入。至于客户最初的文件具应用工程师说是从机台上直接生成的，与我们的系统没什么关系。看起来采集数据华的钱与我们系统关系不大。
至于OO说是话我们产品做的不好，但是去年开发的新产品逻辑和原来的差不多，我做的设计，感觉还是挺有用的。（具体程序是什么样子我不方便说。）最后，我们的产品确实都是围绕数据做的，毕竟是数据挖掘产品，但是还是有很多OO的应用。在我们产品里并不冲突。
您能不能也谈谈您的项目，我们共同学习一下.
谢谢

对于处理海量数据的应用，例如你提到的数据挖掘，数据库无疑是目前最好的解决方案。当然也有专门的数据挖掘系统，其数据并不都保存在数据库里，尤其是大量汇总的中间结果暂存在系统自身的数据文件里。其实这也是变相的数据库，只不过更专用。
我认为OO适合处理复杂逻辑，灵活，容易适应变化。但是对于面向数据的应用，例如报表，还是传统的数据库更合适。

to 楼主：
处理大量数据的，都是数据处理应用。科学计算类不算，实时控制类不算，其它几乎都是。
“在我们产品里并不冲突。”你说得对。OO和DB并不冲突。
数据一经采集，就形成了成本。不管你们的数据采集容易还是麻烦，据我经验其成本总是占大头。系统建成后，系统的安全性，就主要体现在数据的安全上。除非你的数据是没有保留价值的。这种情况比较少。
一般或多或少会在DB里做一些代码（包、过程、函数、触发器等）。有些代码与业务逻辑有关，有些无关。把所有与业务逻辑有关的代码移到应用服务器里，就实现了业务逻辑与DB的分离。这个和OO无关。OO了，并非业务逻辑与DB就分离了；不OO，也不一定就混在一起，也可以分离的。
前面我的回帖说得不妥切，不必把DB里的所有代码移出去，只需移出与业务逻辑有关的代码就可以了。