代码执行效率高手请进，求指导一二！改变底层还是改变web层？

Question

刚在写代码的时候碰到的···想着想着 想看看高手的意见
我的项目是三层架构
我数据库有6张表 A B C D  E F，现在要做一个报表，6个表都关联到！！有个别表数据挺大的报表实现
方式1： Select *** From A left join B on .. Left join C on ..Left join D on ..Left join E on ..Left join F on .. where ..  这样可以实现，然后返回给GridView呈现即可；方式2：Select a,b,c,d,e,f From A 返回每一行 然后对 利用 b参数对 B表读取，c参数对C表读取，以此类推。。我的问题~~用方式1的话 读取一次数据库即可，但要改变创建一个新的 DAO 与之对应，这样就对DAL的代码要改动了···
用方式2的话 可以不用创建新的DAO，在表现层就可以实现了，但这样的话如果页面呈现20行一页，就要读取20*5=100次数据库了求高手指导一下~~

Answer 1

1.查看下表关系以及关联字段类型以及字段是否为逐渐等，这个用于确定构建索引或构建什么样的索引2.先过滤在关联3.Select有用的字段，尽可能的避免用*4.where 子句左面的式子避免逻辑运算，如where ISNULL(xxx,xxx)=xxx，这种数据量大时要和谐掉5.确定你是否一定要Left Join，别忘了还有其它的链接，效率都是有差别的在海量数据时，毕竟算法都不一样么6.的确可以考虑存储过程，不过效果未必会很明显7.用分析工具找出瓶颈问题，这才是关键！！！

Answer 2

“三层”？还纠结“web层”与“DAL层”之间的关系？如果你要改变流程，那么就重新设计业务逻辑层的流程，增加一个只需要调用“计算报表”功能然后就立刻结束的业务逻辑方法，这样你的web层调用这个新的业务逻辑功能（而逐渐丢掉原来的计算报表功能调用）。如果你的web层纠结于DAL层，你根本不能体会到你自己说的所谓的“三层架构”的设计作用来，有什么意义呢？

Answer 3

你决定“逻辑层到底需不需要有一个计算报表的服务功能？”，如果需要，那么就实现它就好了，顶多是把它由同步阻塞的变为异步的模式；如果你的业务逻辑层不支持出报表，那么你的表现层就绕开它而用一大堆琐碎而冗余的BLL功能来代替这个直截了当的BLL功能，也许也能出报表。那么一大堆琐碎的操作拼凑在一起是否就会比一个干净简单的功能操作更快，你自己进行测试是最方便的。

Answer 4

一早起床就看到各位高手的意见，呵呵！to sp1234
逻辑层到底需不需要有一个计算报表的服务功能？
这个问题我昨晚临睡的时候也在想，因为原来的系统没有报表这一部分的，所以我想还是需要在逻辑层有一个报表功能的服务！
另外其实不是纠结在表现层和数据层，可能我表达不太清楚，而是现在需要新增的这一批报表到底是用什么实现？ 1、用原来的逻辑层多次运算构建报表（会打开多次数据库） 2、创建一个专门关于报表的实体类来实现（打开一次数据库即可）；上门各位说的用存储过程，其实也就是后者来实现了~~  感谢各位提醒