业务逻辑写在数据库还是自身应用程序? -问答-阿里云开发者社区-阿里云

开发者社区> 问答> 正文

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

蛮大人123 2016-02-27 19:44:55 2282

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

SQL Java 数据库 C++
分享到
取消 提交回答
全部回答(1)
  • 蛮大人123
    2019-07-17 18:49:18

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

    0 0
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

推荐文章
相似问题
推荐课程