[每周一议]应用是否应该使用大量的数据库特性？

peggye · 发表于 2012-1-16 16:21

学习中。。。。。。

yanggq · 发表于 2012-1-16 16:45

该用的还是用吧,已经花了那么多钱,其实这些应该从架构和开发角度来看.
但是个人不建议那么用,因为对oracle sga的特别是share pool的overhead,如果遇到高并发各种问题都会出来了...

newkid · 发表于 2012-1-16 22:41

fsm 发表于 2012-1-16 15:34
每种数据库都有自己在技术上的壁垒，提供给自己的死党fans的性能和提供给可能迁移到其他种类数据库的应用的 ...

LEFT JOIN 和 (+) 的例子能举一个吗？

newkid · 发表于 2012-1-16 22:43

yanggq 发表于 2012-1-16 16:45
该用的还是用吧,已经花了那么多钱,其实这些应该从架构和开发角度来看.
但是个人不建议那么用,因为对oracle ...

举个例子说明不建议那么用？建议的用法又是如何？
恰恰相反，你说的问题往往是因为不善用数据库特性引起的，比如试图用标准SQL来实现分析函数的功能。

yanggq · 发表于 2012-1-17 09:17

newkid 发表于 2012-1-16 22:43
举个例子说明不建议那么用？建议的用法又是如何？
恰恰相反，你说的问题往往是因为不善用数据库特性引起 ...

我们的数据库并发一般都有30000,任何复杂点的SQL,或者耗费资源多一些的都会成为瓶颈..
你说只是一般情况,我说的是我们的情况,你可以把DW/oltp放一起,如果你的系统不够繁忙,但是不表示别人的都和你一样.
我们不用不表示我们不善用,使用一个特性的时候首先考虑运营维护团队是不是被overburden, 是的,在开发期间是很快乐,你的程序准备用多久?都是自己维护?

yanggq · 发表于 2012-1-17 09:17

我们的机器可能没有你的好,才128 cpu+128G RAM,应该换好机器了.

zhangweizhao · 发表于 2012-1-17 11:48

主要是软件对数据库的兼容长期规划，如果做一套DRP,只是定位中小企业，可以用mysql及其特性，如果想“通用”在软件的初期就应该把业务逻辑放到应用的DAO层，为后期切换数据库准备

hshs_1 · 发表于 2012-1-17 14:29

yanggq 发表于 2012-1-17 09:17
我们的数据库并发一般都有30000,任何复杂点的SQL,或者耗费资源多一些的都会成为瓶颈..
你说只是一般情况 ...

支持楼主的观点。

newkid · 发表于 2012-1-17 23:59

yanggq 发表于 2012-1-17 09:17
我们的数据库并发一般都有30000,任何复杂点的SQL,或者耗费资源多一些的都会成为瓶颈..
你说只是一般情况 ...

我很好奇什么样的SQL算“复杂点的SQL”？你又是怎样拆分成简单的SQL? 这些简单SQL最终不还是得执行，你绕得过吗？如果这样做能奏效，CBO也会替你“拆分”，生成相应的计划。不管你是300个并发还是30000个，尽量不让数据库做多余的动作，这个原则不变。
除非这个复杂SQL里面有部分中间结果是可以缓存到数据库之外的。但那样意味着这部分数据必须是静态的，而且你要自己合并结果，代价就是应用复杂化。
复杂SQL和运营维护团队也不是对立的。如果你的做法仅仅是把复杂性从SQL层面剥离到应用开发层，只不过把皮球踢给另一个团队而已，如果是这样你也可以要求开发团队对复杂SQL负责嘛。

yanggq · 发表于 2012-1-18 10:54

newkid 发表于 2012-1-17 23:59
我很好奇什么样的SQL算“复杂点的SQL”？你又是怎样拆分成简单的SQL? 这些简单SQL最终不还是得执行，你绕 ...

除了单表select/insert/update/delete以外的sql,
因为db和各种编译器均快到极限了
确实cache了很多到不同的层面,所以我们dal层非常强悍.即便这样db很多时候还是撑不住,只能拆分,从app层面早就拆了,每个应用都拆到不同的db,同一个应用也被迫分到不同的db.

[每周一议]应用是否应该使用大量的数据库特性？

浏览过的版块