1
justfly 2019-09-27 14:10:55 +08:00
性能和可维护性的取舍,看你的偏向了。另外从扩展性上来说,应用横向扩展比数据库扩展容易多了,这个也要考虑。
|
2
Michaelssss 2019-09-27 14:12:49 +08:00
你不考虑场景就开始问的话。。没意义,给你两个情况
应用服务器*20 数据库*1 一个是数据库和服务器在同一台主机下 自己手算一下就知道怎么写了 |
3
dog82 2019-09-27 14:14:47 +08:00
在中间件里装载几百万条数据并不好,我倾向 sql 写复杂,前提是队里有 dba。
我是自带 dba 光环的 |
4
wqc466817823 OP @Michaelssss 是的,我懂了,我更倾向于业务层去写判断的逻辑,但是这样的 sql 是 10 几年的老 java 写出来的,我也是看的很蛋疼
|
5
l00t 2019-09-27 14:23:47 +08:00
第二种开销大啊。你反复查询数据库都是有开销的,不要以为只是简单的 select 就没成本了。建立连接,解析语句,以及数据的传输,都有成本。
|
6
Raymon111111 2019-09-27 14:52:51 +08:00
一般来说省数据库的资源更好
业务的机器扩展比数据库的机器扩展要简单很多 换句话说, 数据库的资源更加宝贵 |
7
arrow8899 2019-09-27 15:19:28 +08:00
这样做的前提是 sql 优化得比较好。不然有可能把数据库搞死。
|
8
zdt3476 2019-09-27 15:23:47 +08:00
做个测试啊。
|
9
jjianwen68 2019-09-27 15:24:21 +08:00
感觉一旦开始用 sql 写业务逻辑,很可能 sql 就会越来越复杂,毕竟需求总是在不断变化的
|
10
newtype0092 2019-09-27 15:52:37 +08:00
先 select 出列表,业务层遍历数据,需要子查询的时候要在业务层把条件汇总好,在尽量少的额外查询里获取关联数据,在遍历里重复同样的 sql 做查询就有点蠢了。
|
11
david2011012 2019-09-27 15:54:28 +08:00
mysql 做的最主要的事,我觉得是数据持久化,用 sql 完成业务逻辑的编写,需要考虑性能问题,除非你设计的表结构支持的很好,不然还是乖乖用代码做业务层该做的事情
|
12
zarte 2019-09-27 17:33:47 +08:00
我觉得实践出真理,画点时间自己测试下,然后发结果,看下有没别人做过类似测试有不同结果的,然后找不同。
|
14
xnode 2019-09-27 18:02:33 +08:00
我觉得 理论上 sql 性能高 ,但是实际上 业务需求变动可能太频繁 我不会轻易的用 第一中
|
15
akira 2019-09-27 18:10:08 +08:00
第一种是数据库 cpu100% 一分钟。
第二种是数据库 cpu 10% 30 分钟。 这种情况下,即使方案二的总耗时更高,我们也会选择方案二。 |
16
sagaxu 2019-09-28 00:18:21 +08:00 via Android
|
17
aguesuka 2019-09-28 11:40:03 +08:00 via Android
大部分情况应该选第二种,因为多部署一个应用服务器和数据库成本是不一样的。除非第二种查询的数据大小过大,并且不方便使用缓存的情况。
|