业务逻辑写在数据库还是自身应用程序?
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实现分组统计得到最终结果,是吧?这个时候只能通过自身应用程序实现分组统计?
我想我上面的问题的本质问题是:
两个可互相通讯并对外提供服务的程序各自应该负担什么工作,业务逻辑放在哪,放多少?
希望各位有经验有见解的童鞋给我指点迷津。
Answers
个人观点,简单的放在数据库,复杂的放在程序里。
先说约束,即什么合法什么不合法,比如「账户余额必须是数字」和「账户余额不能小于零」这种简单约束就比较适合放在数据库,因为这是一个不太可能去修改的底线,数据库中所有的数据都必须满足这个条件。
再比如「每天只允许注册 100 个用户」这种约束就比较适合放在程序里,因为不满足这个约束也不会对数据造成破坏,且这个约束很可能在未来修改。
然后是查询,应该尽量在数据库中通过更多的查询条件淘汰掉不符合要求的数据,合适地选择查询条件会让数据库更有效率地利用索引。数据库有很多措施来保证当数据达到一个很大的量的时候依然可以快速地查询,但是如果把数据查到应用里再进行筛选,数据的量可能超出设计时的预期。
分组也应当尽量在数据库进行,这样会减少传输的数据的量,而且数据库只需扫描一次就可以得到所有分组的结果(按照你的做法一,数据库很可能要扫描多次,因为数据库不知道你的几个查询之间的联系)。