这种两种数据库访问方式的设计各有什么优却点？

Question

举个例子，实际业务中有一个明细报表，需要从8个标中结合取数据（业务主表，业务明细标，代码表，其他关联表等）。业务层是与数据访问曾分开的，也就是说要通过DAO来访问数据库。方案1:
  生成一个DAO，里面的逻辑是通过多表联合查询来返回结果。业务层在调用这个DAO获取业务数据，然后返回到前端，方案2：
    首先生成8个基本访问表的DAO，然后通过另外一层EA逐个访问8个基本DAO，取得需要的业务数据。业务层在调用这个EA获取业务数据，然后返回到前端，从再利用性，运行效率，开发效率，维护效率等大家能想到的方面分析一下优缺点。我现在这个项目采用的方案是后者（并不100%是，针对个别效率低的还是选择方案1，但基准是方案2）。

Answer 1

我猜您说的EA层是一层访问DAO的抽象，所以总体来说：方案2比方案1多了一层抽象。
多一层抽象一般会使软件设计更加灵活和更好的复用性，但是这也增加了软件的复杂度。所以要看具体的项目中是否值得多加一层抽象。
譬如改动8个基本访问表的结构的影响是否会迫使EA层也进行改动？EA层的实现是否非常依赖DAO的实现？

Answer 2

你说的第二种方法就是hibernat吧，这种方式主要就是性能差，执行效率低，不适合用户比较多，数据量比较大的系统

Answer 3

这边不用hibernate等任何开源框架，是利用SQLJ（静态SQL）自己写的底层。
EA也是手写的，会从前一层接收查询条件，然后作为参数调用DA，再把取得的结果返回到前一层。这中间，如果有错误，也会在这一层做处理，抛给相应的消息里。
其实，如果按照我自己个人的想法，也就是第一种方法那么做了。但人家这么做也估计也有它的道理，只是我不太能体会这么做的道理。

Answer 4

恩，很多情况下只有自己去参与开发和维护才能理解设计的意图，譬如在修正某个bug的时候，才能理解别人做EA的原委。我认为各种设计是要看怎么用，用在什么地方才能决定它的效率和优点。

Answer 5

如果用框架来对应的话，方案1是MyBatis，议案2是Hibernate

Answer 6

我们不是用框架，是做框架。因为很多查询统计报表实际上都可以用一个sql语句搞定（包括一些稍微复杂的），但是采用方案2的话，就要编很多逻辑java代码，由java来做。好处呢，也许是java代码看着更容易理解，以后换其他人好维护。但我始终觉得如果是这种复杂报表处理，还是由sql来实现，无论开发效率还是执行效率都很高，包括维护，以后只改sql语句就可以，其他java代码也无非是改变一下接受参数什么的，不涉及业务，还方便测试。

Answer 7

但我始终觉得如果是这种复杂报表处理，还是由sql来实现
如果sql可实现的尽量用sql做了,如果sql做了,如果是需要大量消耗cpu的处理时需要考虑性能问题了
sql和代码的性能要保存平衡
如果让数据库做太多的东西数据库有可能会一直忙碌而服务不过来

Answer 8

对对，这边资料上也这么说过。那么这就是说虽然有的时候java方式实现会麻烦些、效率差点，但是考虑全都让数据库做的话，数据库那边也会出现瓶颈，所以把它拆分开来，由java服务器这边分担些？
不过又考虑，数据库是不是也有集群，如果也能用，硬件上数据库这边多分担些，java应用服务少分担些不是也能解决？

Answer 9

如果基表数据量小，采用方案2没什么问题，基表数据量大，你先取基表的操作会很耗资源，把数据放到你的DAO层再来做join又增加你应用程序的负担，这种情况下还不如用方案1，把复杂性交给数据库主流数据库对大数据量的多表join都有查询优化策略，在数据库底层的缓冲区里做关联也比你DAO层把数据都拿到内存里做要高效

Answer 10

一般报表的数据量都不小 所以用方法一的多一些
而且都是用SQL 这样方便于优化
方法二 不太推荐修改 优化起来 会很麻烦