1
kevinhwang 2019-04-22 13:55:44 +08:00
你能这么问证明你团队无约束。
如果外包请疯狂 join 表然后愉快玩耍。 后续要自己维护的请慎重!!! |
2
zarvin 2019-04-22 13:58:16 +08:00
我公司后台开发好像就是很多 join,那 sql 语句贼长
|
3
YzSama 2019-04-22 14:11:10 +08:00 via iPhone
我宁愿分开查,增加缓存。。
|
4
passion336699 2019-04-22 14:11:14 +08:00
是这种吗, 下面还有很多很多截不完了.... |
5
NoKey 2019-04-22 14:12:16 +08:00
我们这里一般都是分开,然后在编程语言里自行查找组合需要的数据
|
6
adzchao 2019-04-22 14:13:58 +08:00
@passion336699 这不是很正常么 我感觉你这还不是复杂的
|
7
onepunch 2019-04-22 14:14:46 +08:00
小表问题不大。如果表增长无法预期你还是别这么做了
|
8
rockyou12 2019-04-22 14:16:58 +08:00
统计业务请一定用代码来写,千万别 join N 级。像我们很多 1000 多行,子查询 3、4、5 层的 sql 完全没办法维护……
|
9
Mmiracle110 2019-04-22 14:17:21 +08:00
join 表多的话,表内数据小还好,表大的话,你试试......
|
10
sjzzz 2019-04-22 14:20:26 +08:00
....建议换一个团队。
|
11
VensonEEE 2019-04-22 14:21:27 +08:00
你们怕啥没见过两万多字的 sql,存储过程。以前某行业应用,报表系统,全 oracle 存储过程,改个逻辑要重写一个星期。 真是佩服 oracle 的性能。
|
12
payboy OP @passion336699 是的,复杂点还有各种子查询。
|
13
Mazexal 2019-04-22 14:45:57 +08:00
第一, 不好做缓存优化
第二, 增加维护成本 第三, 不适合后期做分库分表 第四, 不适合做 sql 查询优化 优势: 一开始写的速度快那么一丢丢 结论你自己想吧 |
14
est 2019-04-22 15:23:41 +08:00
JOIN 没啥不好的。
无脑 JOIN。。。只要 dba 角色那个人能管理得过来也挺好的。 |
16
guyujiezi 2019-04-22 15:41:22 +08:00
join 挺好的,SQL 语句越拼越有意思,还可以为将来系统优化什么的创造 KPI
|
17
Removable 2019-04-22 15:47:01 +08:00
@rockyou12 #8 别说了,我接手的有个模块,之前做的那个沙雕把所有的业务都放到存储过程里了,那维护起来就一言难尽
|
18
DiverRD 2019-04-22 16:19:02 +08:00
join 一时爽,迁移火葬场
|
19
xuanbg 2019-04-22 17:35:33 +08:00
都不会写 sql 吗?几个表 join 就把你们吓坏了?只要单表数据量不上千万级别,join 上 10 来个表数据也能秒出好不好。
话说单表数据量要是上千万级别的,做表结构设计的那个可以解雇了。 |
20
tiedan 2019-04-22 18:49:18 +08:00
我选择 join
|
21
zhchyu999 2019-04-22 18:52:14 +08:00
后台就怎么爽怎么来,量大 mysql 还是简单查询比较好
|
22
mk0114 2019-04-22 20:26:54 +08:00
可是有些分页或者过滤一定要联合其他表查询该怎么办呢?
|
23
glacer 2019-04-22 20:32:33 +08:00
统计型 SQL 敢在业务数据库上跑?不怕分分钟拖垮掉?
|
24
lvchao 2019-04-23 09:17:18 +08:00
不用多表 join 对于分页怎么处理
|
25
gosansam 2019-04-23 12:49:45 +08:00
写过一段上午写好 睡个午觉起来就看不懂的 sql 了 join 也就七八个 然后子查询一堆
|
26
jianmo1997 2019-04-23 20:03:33 +08:00
在我司前一种方式一般都会被 DBA 杀了祭天
|