计算逻辑在mysql还是程序_业务逻辑写在数据库还是自身应用程序？

SQL应该负责怎么样的CURD，分组、排序、可能根据业务逻辑只是选择性查个别字段、使用SQL函数等等让不让数据库做？还是自己用编程语言(比如java、c++)写的应用程序里处理数据？

实例：统计2015-03-22 ~ 2015-03-24期间全国每个城市/省份每天的访问ip量。

假设查询涉及的表的数据量为S。考虑以下三种方式。

做法一：

在一个以天为步进单位长度来遍历2015-03-22 ~ 2015-03-24日期范围以及全国每个城市的循环里，执行countIp(visitDay, cityCode)统计某个城市或省份某天的ip量。核心SQL：

SELECT COUNT(DISTINCT user_ip) FROM pv_access WHERE visit_date_time BETWEEN {某天最早时间点} AND {某天最晚时间点} AND city_code = {某个城市的编码}

SELECT COUNT(DISTINCT user_ip) FROM pv_access WHERE visit_date_time BETWEEN {某天最早时间点} AND {某天最晚时间点} AND city_code LIKE {模糊匹配某个省的所有城市}

做法二：通过以下SQL获取数据，然后在应用程序中做分组统计。

SELECT visit_date_time, city_code, user_ip FROM pv_access WHERE visit_date_time BETWEEN '2015-03-22 00:00:00' AND '2015-03-24 23:59:59' AND city_code in ({所有城市的编码})

如果没有统计省份的需求，有第三种做法，直接执行SQL按【天+城市】分组统计：

SELECT DATE_FORMAT(visit_date_time,"%Y-%m-%d") as day, city_code, ipCount FROM pv_access WHERE visit_date_time BETWEEN '2015-03-22 00:00:00' AND '2015-03-24 23:59:59' AND city_code in ({所有城市的编码}) GROUP BY DATE_FORMAT(visit_date_time,"%Y-%m-%d"), city_code;

我自己的分析：

涉及循环n次访问数据库，每次取一个分组的统计结果，时间复杂度为(nS)。优点应该是易于维护。

数据库负责简单的查出记录集，不负责统计，一次性取出统计所需的所有数据，然后让应用程序做分组统计等处理。但是这样不就增加了传输量吗？因为可能我们需要的最终结果只是一个统计值(比如这个例子)，但为了将统计工作转移到应用程序，就必须传输更多的数据。传输量为(S)。

一条SQL语句获取最终结果则只需一次请求，时间复杂度为(S)。但压力大部分会转移到数据库？

如果涉及分组统计，而分组不是互斥的(上面的例子【天+地区】分组不是互斥，既有城市又有省份)，那么应该无法使用直接用SQL实现分组统计得到最终结果，是吧？这个时候只能通过自身应用程序实现分组统计？

我想我上面的问题的本质问题是：

两个可互相通讯并对外提供服务的程序各自应该负担什么工作，业务逻辑放在哪，放多少？

希望各位有经验有见解的童鞋给我指点迷津。