无论是正常查询，还是过程，最终都是生成你要的数据；

看你报表需求，善于使用那个就用那个做，复杂的用过程可以看的更清楚和方便调试

存储过程维护麻烦,能用数据查询当然用数据查询好

最好是  数据库建立视图，报表使用查询

因为报表可能会多处引用该视图，那维护起来直接改视图就所有报表都更改了逻辑

存储过程的弊端

1.架构不清晰，不够面向对象

 存储过程不太适合面向对象的设计，无法采用面向对象的方式将业务逻辑进行封装，业务逻辑在存储层实现，增加了业务和存储的耦合，代码的可读性也会降低，

2.开发和维护要求比较高

存储过程的编写直接依赖于开发人员，如果业务逻辑改动较多，需要频繁直接操作数据库，大量业务降维到数据库，很多异常不能在代码中捕获，出现问题较难排查，需要数据库管理人员的帮助。 

3.可移植性差

过多的使用存储过程会降低系统的移植性。在对存储进行相关扩展时，可能会增加一些额外的工作。

存储过程与SQL语句如何抉择

架构设计没有绝对，只有在当前的场景下最合适的。

普通的项目开发中，不建议大量使用存储过程，对比SQL语句，存储过程适用于业务逻辑复杂，比较耗时，同时请求量较少的操作，例如后台大批量查询、定期更新等。

（1）当一个事务涉及到多个SQL语句时或者涉及到对多个表的操作时可以考虑应用存储过程
（2）在一个事务的完成需要很复杂的商业逻辑时可以考虑应用存储过程
（3）比较复杂的统计和汇总可以考虑应用后台存储过程