恩

我是菜鸟，抱着学习的角度来的。没什么可说的但，看帖不回是犯罪。我认为大家说的都很有道理，
至于分歧完全是工作不同导致的！！！

我是菜鸟，抱着学习的角度来的。没什么可说的但，看帖不回是犯罪。我认为大家说的都很有道理，
至于分歧完全是工作不同导致的！！！

中庸之道才是最好的解决办法，OO要考虑DB，DB也要照顾OO，这样才能有可维护性和性能都适中的软件，不会走极端，
OO--> <--DB。

也不是没道理

给各位一个建议：
1、用什么语言、什么平台、什么架构或者什么设计思想都是由具体的项目决定的
2、SQL到OO得过度只能说是软件技术的一个发展历程。由于软件的复杂，所以出现了OO,不复杂用OO干吗?
3、楼主的感受可能是由于业务上、商业上、公司人员水平等的一些行为导致的，
如果业务不算复杂，可以用OO也可以不用
如果业务复杂，有钱的话也没关系，有的是人维护
归根结底讲：需求和人员水平决定了采用的技术。不是几句话就能讲完的，这是由每个公司的技术大牛决定的。复杂的很，有客观的有人为的，初级程序人员需要做的就是把某一领域的技术做强，各领域技术是相通的，不用在乎落伍不落伍，到了一定的水平，技术之间的转换很快的。

学习中。

现实就是这样。。根据数据量的增长。。数据越来越多。应该执行的速度越来越慢。。触发器，存储过程有甚者已经超过好几千行。比应该程序的代码很多。。我很无奈。原来是服务器现在是小型器。。慢慢开始优化。。现在好多架构师开始研究NoSQL ,缓存。。存储..云计算机。。。希望在未来数据增长的同时把性能提上去。 OO 我很看重。。很多人只会听和看而不能灵活的运用。banq 大师常讲的DDD 至今还没有真正的在项目中使用过。。真想实践一下啊！。。期待哪一天的到来。

系统是多样性的，你所做的系统更专注于如何快速查找仓库里的数据而已。

真正的开发，是不需要数据库的。数据保存在内存里。

这话太绝对了，呵呵！
主要看需求，是否需要持久化。

主要看需要，Java是开发语言，SQL的话是DB相关的，事实上，没有任何关系。楼主的观点是工作造成的。

具体问题具体分析，对项目有利就用……哈哈

数据库是的定位需要重新改变，软件中的数据交互，一直是内存级别的，持久化到硬盘的话，就像把数据交互的地方放到硬盘，要是那样的话，我们还要内存干嘛，干脆CPU跳开内存把，直接到硬盘读数据好了。需要注意的是，数据交互和持久化是相互独立的两个概念。

我们需要反思的是，内存的意义，以及我们用数据库管理数据的初衷。我们以前直接用SQL操作的原因在于可恢复性问题，若果保存到内存的话，一死机就没了。回到现实中，一个数据在一个人的脑中，这个人死了，那么数据就没了，这是正常的。如何保证数据不丢失，多个人记住或者写在纸上就行了，就是现在的集群、热备等技术。

以前没有相关技术支持，所以依赖数据库很是理解，但现在技术出来，还依赖的话，未免有点太袒护了吧。

只有没有搞过系统的人才热衷于技术。
在中国，搞技术的没有几个能发达的。不能发达就意味着，基本上有资金开电脑公司的都是不懂技术的，除非你爸是李刚。

从用户的角度看，对技术也不敏感。用不的技术工程师在用户公司都是弱势群体，只要销售把他的领导公关好，用户工程师无论如何都要验收，哪怕你的产品错漏百出。

所以，在中国，搞技术必然饿死。按进度或者提前完成才是准则，哪怕系统以后出问题，可能半年后崩溃之时，你已经升迁或者因为你的经历跳槽到更高新的公司。