求解释SQL Union VS OR

无视

很复杂的逻辑现在我倾向于放到app那边作。原因有两个：

1.db的logic不能unit test.可能只能做很复杂的integration test.

2.可扩展性差。logic在db这边产品刚开始可能帮助你提升performance，但随着产品scale的增加db的负担越来越重，resource racing的问题可能不可避免，从硬件上scaleup效果局限。

但这一直是很有争议的话题，我自己也在不同的阶段摇摆不定，现在我比较倾向于放在app这边。

典

原帖由 无视 于 2012-3-23 10:00 发表
很复杂的逻辑现在我倾向于放到app那边作。原因有两个：

1.db的logic不能unit test.可能只能做很复杂的integration test.

2.可扩展性差。logic在db这边产品刚开始可能帮助你提升performance，但随着产品scale的增加db的 ...

同意，用APP做是正道，在DB里做只能说有时候可以，

rainmore

同意，用app的维护性更高。

bigwood

你确定是从一个表中拿数据吗？为什么有这么多table scan?

如果两个单独condition的查询row count，比join起来的row count小得多，而且两个union查询条件比较简单，比较利于sql server建立plan, 那union 会比 or 快得多，有的时候甚至建立#temp，利用physical io都要快。你甚至可以试一下不用union, 直接插入两个#temp。如果是这个情况join的条件可能有问题。

如果一个大的，bad join，会使整体的返回数据量增大，而且没有好的index 来查询， 同时复杂的查询条件，如果没有很可靠的statistics,会产生一个很差的plan.

porcorosso

原帖由 无视 于 2012-3-23 11:00 发表
很复杂的逻辑现在我倾向于放到app那边作。原因有两个：

1.db的logic不能unit test.可能只能做很复杂的integration test.

2.可扩展性差。logic在db这边产品刚开始可能帮助你提升performance，但随着产品scale的增加db的 ...

觉得也比较flexible

无视

logic放在app这边缺点也是比较显著：

1.根很多传统理念相违背，很多人认为store proc就是database的api,提供数据封装功能，而不是简单的data store. 而且database的生命周期通常长于app，这样app的平台移植就很方面（我觉得也很罕见）。

2.未经logic处理的大量数据，会有network latency的问题（还是要适当的放些condition在里面的）

3.大量logic会给app负担加大，尤其是大数据量运算的话，这可能要把app那边的server更加细分。

我的感觉是两种观点都有自己的道理，不能只走一个极端。

kuxxc

Surely you don't want to use UNION when OR is the logical choice.

Fix your index.