一次小项目的思考

数据库已死,标题过大,一个敏感话题,在哪里都引起争执.
起先读到,很有新意,把数据库只当作数据持久的载体,说的不错,所有的业务数据都放进缓存,在内存中去计算.这是一种理想状态,过于极端了,或者说太难做到了.

另外所有说数据库摆脱不掉的朋友,数据库已死,不是说不去使用数据库,而是说从数据库出发建模的时代过去了.

这就好比说“楼主去用hibernate去做个BI吧、还有数据仓库、数据挖掘”
hibernate并不妨碍你对数据库做这些附加应用，也不妨碍你在同一个项目里用iBatis做OLAP型的功能。

你这不就是抬杠：说用hibernate和说对象数据库不就是一会事，进行复杂统计或者报表的时候，面向对象力不从心的地方就是，对象关系负责，形成关系网。

你的意思是一个项目一旦用了hibernate就必须从一而终，不能同时用SQL了？

大型应用的数据库生命周期远远大于应用的生命周期……

说到抬杠，就再抬一次吧，呵呵。其实你说的这个问题，和hibernate也没有什么关系。hibernate对数据库的操作，最终的，还是sql，而且，hibernate本身也提供了对native sql的支持(不考虑性能问题)。
这些，只能说明对象的表现力不够，面向对象不够好。形成关系网。那我只能猜测，你们有更加高级的方式吧？如果可以的话，是否可以也谈谈你们的解决方式，实际上，对于一些非常复杂的业务逻辑，相信很多人都比较头疼。

同意，也赞同LZ的观点，先从数据库建模出发，会导致使用面向对象语言Java去写出面向过程的代码，导致类的职责不明确或过于庞大...

无论是面向过程还是什么OOA、OOD、OOP的面向对象，在真正实施起来时觉得还是以场景为重点来抉择合适的方案

像前面有说做一些大数据统计，大数据的计算，涉及到数学概念较强的应用系统，面向过程的方式会比面向对象的思维适合吧？

面向对象建模的优点在于能自然的表现现实世界的概念，从而让你所设计的类和现实事物自然的联系起来...

无论如何，存在即是合理

OO与关系数据库根本就没冲突
只是项目中实施方法不同而已
1、OO为中心，先建类，实现方法，实现方法中需要存储时，再去建表
2、数据库为中心，自以为知道哪些实体存在，预先给它建表，其实目的还是存储实体

如果用第2种，就导致，当业务复杂时，人的思维有限，代码信赖于表结构
大家都清楚，代码表达的业务逻辑复杂时，当表结构变动大时，改起来就痛苦了

因此，数据库应该只是支持（实现）OO业务逻辑一个工具而已，J道说的没错，只是那是终极理想而已，
在目前大环境下不现实

“一套自己的完整的理论体系”，跟你程序设计有毛关系啊？
麻烦你专业的讲一下，你做软件设计时（DBMS除外），数据库的那套理论体系给予你了什么帮助？是怎么帮助你的软件开发处于“可控状态”的？
你做系统分析、软件设计时，不会就是看谁的理论基础雄厚，而不管那理论是针对哪方面的？