一次小项目的思考

最近的一个项目，四个开发人员，大概做了一个月多一点，从需求，到最终代码的完成。
写思考，我想，主要还是要回顾一下在项目中遇到的问题，或是有什么比较好的经验，新的体会值得记录下来，以供以后参考。在这里，主要是要思考两个方面的问题，数据库和测试。
1. 数据库
   对于数据库，在j道上面有这样一篇文章《数据库已死》，其主要思想，个人感觉，主要还是对象与关系的问题，我们现在的主流已经是面向对象，但现在，可能很多公司仍以数据库建模作为其一条主线，首先进行数据建模，erwin，powerdesigner，然后创建相应的表，下面，就使用myeclipse,hibernate tools等生成相应的实体类，以及相应的映射文件。包括以前的几个项目，者是在开始花了大量的时间进行数据库的设计，中途加入的项目，也会在进入项目组的开始阶段让你熟悉其数据库的表结构，当面对大量的表的时候，看着E-R图上面的“蜘蛛网”的时候，可能，就已经晕了。
实际上，在面向对象的时代，数据库只是状态持久化的一种手段，数据库的表结构完全可以通过Hibernate等ORM工具自动生成。
在这个小项目中，前期，并没有花大多的时候在数据库的设计上，在初期建模了一些核心对象，创建相应的实体类，加上相应的注解，借助于hibernate的hbm2ddl，完全可以由hibernate自动生成相应的表结构。当增加新的对象的时候，也只需要定义其类结构。
并且，可以提供不同的sessionfactory，分别针对测试等环境，也可以做到一定程度的database migration。
2. 测试
   TDD，BDD，持续集成~~~~等等，不知道有多少公司实施了，并且实施的情况如何。在以前的项目中，最怕的，就是测试数据依赖于其它的模块，当跑一次测试，还需要去跑一下由其它小组开发的模块，当对该模块的业务不太了解的时候，测试起来，还是比较麻烦的，还有可能需要麻烦其它小组的人员来为我们提供相应的测试数据。
这种情况，其中一个原因，测试代码太少。所以在这个项目中，针对一些核心的，或是较复杂的业务逻辑，都提供了相应的测试代码(当然，这里有一个粒度的问题)，虽然在开发过程中，需要抽出一部分时间来编写相应的测试代码，但在实际过程中，效果还是比较明显的。

确实，数据库思维最终导致数据库单点瓶颈，系统没有水平伸缩性，而采用面向对象建模，再加上对象的缓存，必要的时候能引入异步，这样就能在一定程度上增加系统的伸缩性，但是这也需要一定的挑战，比如缓存和数据库之间如何同步更新，以及内存事务如何控制等问题。

楼主想的太简单了.
数据库系统发展这么多年了,已经形成了一套自己的完整的理论体系,你看书店里面有多少讲专门数据库理论的书?这是一门学问,有理论基础所以才能屹立不倒.
而orm,hibernate这些东西,最大的问题就是没有自己的理论体系,因此其发展受到很大的局限,基本上处在不可控的状态.
楼主对问题的分析和理解,实在是太缺乏专业精神了.

恩 oracle真该羞死啊...

不知道LZ用hibernate去实现过复杂统计，复杂报表么？这时候你会发现hibernate多么力不从心。

仅仅拿个hibernate，就去鄙薄ERwin之类的建模工具，未免浅薄。关系建模有自己的应用场景，存储过程仍然是坚如磐石的东西，牢牢占据了电信、银行、保险等等企业应用的顶峰。

问一个问题：
复杂的统计，复杂的报表，统计的是什么？报表的数据哪里来？再复杂的报表，再复杂的统计，最终到达数据库层面的，无非就是那层简单的数据库表之间的关系，这于hibernate又有何干？无非最终又绕到什么hibernate性能差之类的吧？

也不是说想得简单，无非是在小项目中的一次尝试。

对，这也是“数据库之死”最主要的思想了，而jdon推荐DDD思想，也是基于这个吧。

好奇怪的想法：
1>无论使用什么技术，持久化现在的解决方案都是数据库，如果你能提出自己使用hiberante+自己的持久存储(比如自己写数据库)来解决的话，那是超级大牛
2>如果自己做不了持久存储，使用数据库的话，那：
   凭什么说以数据库设计，结合ORM有问题。进一步说，你使用hibernate+文件存储(自己定制hiberante的sql的引擎)也能行，但是你的解决方案有多大价值。
    你使用hibernate加上自己的设计，可以解决水平的问题，单是单点性能的问题你如何解决？绝大多说在百万级的数据下(并发<100)，不需要考虑水平扩展，恰当的使用数据库，单台机器就解决了，而你只是觉得ORM是外能，根本不考虑充分利用数据库性能，用了10台机器，对客户来说会使用谁的方案。
3>终极的方案是：定制自己的存储和分布数据策略，和使用hiberante没什么关系，只是一种工具。 淘宝没有用hiberante，仍然做的很好。

每一种技术都有适当的范围，不是万能的钥匙。

数据库是瓶颈主要原因有二种：
1>应用体系结构上不支持分布性，类：google等其它的解决方案

hiberante不是这种解决方案的技术

2>使用数据库上，没有考虑数据库的使用方式

这是自己自己麻烦的问题，和面向对象没什么关系。极端的举个例子，如果你写个程序写成死循环了，那么是不是操作系统设计的问题？你写的程序会不会考虑运行的环境？

百度的开发经理说过一句话：如果你的程序能让Cpu和IO同时达到95%以上，google和百度肯定会录用你。

经常我们是：分布式做不到一个很好的方案(和大公司比)，不愿意充分利用现有的成熟的技术。在应用层面拿面向对象说事，范围还是太窄，需要开阔眼光。

对企业来说，性价比第一位，不需要考虑分布和扩展；对电信和互联网来说，需要分布和可扩展。学习和自己的定位有关，不同的行业有不同的技术要求。

要专业，而不是泛泛而谈，人云亦云，要有自己的独立的判断能力。

我觉得数据库没这么简单,有的公司牛JAVA拉数据库 有的公司是牛数据库拉JAVA 现在公司考虑的都是复用和快速高效的开发  如果新加一个扩展都没有工作量 怎么能有细水长流的业务呢...