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

Question

SQL应该负责怎么样的CURD，分组、排序、可能根据业务逻辑只是选择性查个别字段、使用SQL函数等等让不让数据库做？还是自己用编程语言（比如java、c++）写的应用程序里处理数据？
实例：统计2015-03-22~2015-03-24期间全国每个城市/省份每天的访问ip量。
假设查询涉及的表的数据量为S。考虑以下三种方式。做法一：
在一个以天为步进单位长度来遍历2015-03-22~2015-03-24日期范围以及全国每个城市的循环里，执行countIp(visitDay,cityCode)统计某个城市或省份某天的ip量。核心SQL：
SELECTCOUNT(DISTINCTuser_ip)FROMpv_accessWHEREvisit_date_timeBETWEEN{某天最早时间点}AND{某天最晚时间点}ANDcity_code={某个城市的编码}
SELECTCOUNT(DISTINCTuser_ip)FROMpv_accessWHEREvisit_date_timeBETWEEN{某天最早时间点}AND{某天最晚时间点}ANDcity_codeLIKE{模糊匹配某个省的所有城市}
做法二：通过以下SQL获取数据，然后在应用程序中做分组统计。
SELECTvisit_date_time,city_code,user_ipFROMpv_accessWHEREvisit_date_timeBETWEEN'2015-03-2200:00:00'AND'2015-03-2423:59:59'ANDcity_codein({所有城市的编码})
如果没有统计省份的需求，有第三种做法，直接执行SQL按【天+城市】分组统计：
SELECTDATE_FORMAT(visit_date_time,"%Y-%m-%d")asday,city_code,ipCountFROMpv_accessWHEREvisit_date_timeBETWEEN'2015-03-2200:00:00'AND'2015-03-2423:59:59'ANDcity_codein({所有城市的编码})GROUPBYDATE_FORMAT(visit_date_time,"%Y-%m-%d"),city_code;
我自己的分析：
涉及循环n次访问数据库，每次取一个分组的统计结果，时间复杂度为(nS)。优点应该是易于维护。
数据库负责简单的查出记录集，不负责统计，一次性取出统计所需的所有数据，然后让应用程序做分组统计等处理。但是这样不就增加了传输量吗？因为可能我们需要的最终结果只是一个统计值（比如这个例子），但为了将统计工作转移到应用程序，就必须传输更多的数据。传输量为（S）。
一条SQL语句获取最终结果则只需一次请求，时间复杂度为(S)。但压力大部分会转移到数据库？
如果涉及分组统计，而分组不是互斥的（上面的例子【天+地区】分组不是互斥，既有城市又有省份），那么应该无法使用直接用SQL实现分组统计得到最终结果，是吧？这个时候只能通过自身应用程序实现分组统计？
我想我上面的问题的本质问题是：两个可互相通讯并对外提供服务的程序各自应该负担什么工作，业务逻辑放在哪，放多少？
希望各位有经验有见解的童鞋给我指点迷津。

Answer 1

个人观点，简单的放在数据库，复杂的放在程序里。先说约束，即什么合法什么不合法，比如「账户余额必须是数字」和「账户余额不能小于零」这种简单约束就比较适合放在数据库，因为这是一个不太可能去修改的底线，数据库中所有的数据都必须满足这个条件。再比如「每天只允许注册100个用户」这种约束就比较适合放在程序里，因为不满足这个约束也不会对数据造成破坏，且这个约束很可能在未来修改。然后是查询，应该尽量在数据库中通过更多的查询条件淘汰掉不符合要求的数据，合适地选择查询条件会让数据库更有效率地利用索引。数据库有很多措施来保证当数据达到一个很大的量的时候依然可以快速地查询，但是如果把数据查到应用里再进行筛选，数据的量可能超出设计时的预期。分组也应当尽量在数据库进行，这样会减少传输的数据的量，而且数据库只需扫描一次就可以得到所有分组的结果（按照你的做法一，数据库很可能要扫描多次，因为数据库不知道你的几个查询之间的联系）。

Answer 2

这不是业务逻辑，而是数据库最基本的功能。一般说业务逻辑放在数据库是指用存储过程等方法把业务特定的逻辑放在数据库中。我个人不赞同这种方式。另外省份是可以，也应该用第三种方式统计的。你需要的是一张城市代码和省份对应关系的字典表。