我觉得从扩展性来讲，包括从单体到分布式的各种演进，都是在不断提升系统的扩展性，能支撑更多的用户使用量，简单讲就是支撑各种高并发。
如果你能接受这一点的话，数据库只做增删改查，应用层负责加减乘除和各种检查逻辑、通过各种缓存和数据库连接池减少对数据库的访问压力，从而提升系统的吞吐量是更合适的，而不是一股脑把所有东西一竿子捅到数据库上，再牛逼的数据库也承受不了这样的压力，数据库很容易成为瓶颈。
另外顺便说一下，现在数据库各式各样，最终有哪些数据库能存活下来还真不一定，这就意味着如果你选了一个偏门的数据库，各种逻辑写在sql里，将来迁移数据库想想都头疼。
【 在 Xjt 的大作中提到: 】
: 标 题: Re: 好奇问一下
: 发信站: 水木社区 (Wed Apr 5 23:04:28 2023), 站内
:
: 我表述的不够精准，随便灌水没仔细想了，我这里的sql其实是想代指所有各种类型的数据库
:
: 我一直的观点就是在非超大型互联网企业，数据库可以成为业务的核心，而外层的代码越轻越好越薄越好，仅仅负责输出结果而不是业务逻辑，最理想的未来（实际上技术早就能做到了）是数据库直接暴露Rest API给前端调用，有点GraphQL的感觉。
:
: 在中小型应用里，数据库的好处实在是太多了，比如事务一致性，用Java得一堆笨重的框架，数据库天生就能搞定。
: 【 在 mopo 的大作中提到: 】
: : 嗯，我理解sql的语法优势，不过你这说法有点sql中心论了，很多框架的出现和演进都是需求驱动的，我不认为他们的出发点都只是为了更好的支持sql，在实际项目里的数据查询可以是多种层次的，最底层的可以是hadoop/spark算子，最高层的可以是前端界面点点点，这些可以用sql实
: 郑部梢圆挥茫侵旨赴傩械膕ql我也见过，大部分是统计报表用的，但是可维护性不比裸的hadoop算子好多少，可能还没有后者好懂。另外一个例子是ES系或者自研的倒排索引系统，这个支撑的数据量说是支撑互联网半壁江山不夸张吧，也跟sql没啥关系。
: :
:
: --
: ※ 修改:·Xjt 于 Apr 5 23:05:12 2023 修改本文·[FROM: 101.80.249.*]
: ※ 来源:·水木社区
http://www.mysmth.net·[FROM: 101.80.249.*]
--
修改:Xjt FROM 101.80.249.*
FROM 124.64.23.*