会用JOIN,却不懂编程的“程序员”(6)

  • A+
所属分类:MySQL python

1.1. 前言

之前的文章应该已经是彻彻底底的证明的拆分join带来的好处是极大的,并且基本已经打破了一些人的谣言。那(“装饰器”+“拆分JOIN”)就这些能耐了吗?答案是否定的。让我们来看一下基本上在每个项目中都是要做的。

1.2. 场景

随着项目的发展需要对业务进行切割。如将“商品管理”和“订单管理”进行分开。这里的分开是在“程序”和“数据库”同事切分。这时候商品数据和订单数据都不是在同一个库因此要做到跨库查询。

大多的项目说到要项目切割的时候,那基本上就是一个噩梦。基本上就是需要对项目进行重构,重新开放了。就想我再公司说,这个表已经过大,需要拆分,程序员总是说:“这个改动太大”一样。一看改动太大的原因是因为,他们的代码中对数据库的操作充满的join,因此,他们说的改动太大这是肯定的。

1.3. 装饰器完成跨库表查询

我们现在模拟券表(coupon)在test1数据库中。数据为:

和之前一样我们,使用的是(“装饰器”+“拆分JOIN”)的方法。

1.4. 实现程序

这里我们在创建一个装饰器方法use_db,这个方法可以传入一个参数conn:

conn:数据库的链接。

之后我们在get_coupon_info方法上面添加一个annotation:@use_db(conn=conn1),其中conn1代表数据库test1的链接。这样之后查找券的信息就是在test1中查找的了。

代码如下:

输出结果:

源代码:use_decorator_diff_db

从上面可以看到最后一列的券的信息,就是从test1库的coupon表关联来的。

1.5. 总结

通过系列文章的介绍我们知道拆分jion将会给我们带来各种的好处。

通过查分jion之后我们会看到系统现象是,应用程序的CPU利用率会上去。而数据库的CPU会下来,这也是我们想要的结果。如果一个应用程序CPU太高了你可以扩展多个应用程序。这中架构也是我们想要的。如果是使用JION那数据库的CPU上去了。我们将会很难扩展,并且扩展的成本、人力和物力将会是层倍的增加都不止。

到了这里,如果你还是觉得jion比拆分jion的效率高,代码量大的话。我只能说对不起了:我只是一个不称职的DBA,一个不懂得写复杂SQL的DBA。

以上乃个人观点。如果有得罪到大神们的地方,在这里我对你们说对不起,请原谅小菜鸟我的无知。当然,我更喜欢的是交朋友。有什么问题或不好的请多多指教。

 

昵称:HH
QQ:275258836
ttlsa群交流沟通(QQ群②:6690706 QQ群③:168085569 QQ群④:415230207(新) 微信公众号:ttlsacom)

感觉本文内容不错,读后有收获?

逛逛衣服店,鼓励作者写出更好文章。

weinxin
微信公众号
扫一扫关注运维生存时间公众号,获取最新技术文章~
HH

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

目前评论:1   其中:访客  1   博主  0

    • meike 0

      想问一下如果原来是多表联合查询得到分页的结果,那你以那个表作为基准取出需要分页的条数呢?