关系型数据库使用中的误区系列:不要把业务放进数据库

任何东西都不是多多益善,帕累托法则在生活中处处体现,关系型数据库就是一个典型的例子,你会发现80%的业务跑在20%的功能之上。显然,我和帕累托一样,不相信均匀分布在真实生活中体现。 以下摘录自Andy Warfield的《The 80/20 rule… for storage systems.》,“80/20 法则通常被认为是源于意大利经济学家维尔弗雷多·帕累托。帕累托出生于1848年,他是(至少被认为是)占领运动的早期成员之一。他发现意大利国家财富的80%是掌握在几乎少于20%的人口手中的。由此发散开来看,80/20法则在其他方面的应用同样值得注意,也是很有趣的:因为帕累托观察发现他的园子里的80%的豌豆产自于20%的作物上(他似乎更喜欢数豌豆而不是其他豆子)。" 很多程序员在做到某个阶段的时候都会来问我,要不要用触发器?要不要用存储过程?等等一系列类似的问题,你也会发现从搜索引擎可以找到很多文章在围绕这个话题展开分析,介绍各种各样的技术等等,但我想申明我的观点,在OLTP的系统设计中,请不要把你的业务逻辑以触发器和存储过程形式放到数据库中!OLTP只能保存关系,也许有些feature一时帮了你的忙,但是后患无穷。…

关系型数据库使用中的误区系列:业务字段展示字段傻傻分不清楚

松本行弘在《代码的未来》中领悟道,这世界上没有java编程,没有ruby编程,更没有php编程,其实这世界上只有编程这两个字呀! 好喜欢这句话,我觉得数据库编程也是一样的道理,虽然我们在谈数据库,更多的探讨是如何拥有编程的思维去处理这些问题。当碰到跨语言,跨平台的编程时,我们会称之为架构,但其实本质还不是在编程么?最后你会看到,人的架构永远大于软件架构,编程技巧只是人类处理真实世界问题在代码中的体现!这是我的感悟。 作为系列的第三篇,我们谈谈关系型数据库常见的问题,也是初创型公司不能高速发展乃至转型的羁绊,业务字段展示字段傻傻分不清楚! 先从一个简单的例子开始说起,我们总会设计各种各样的管理系统,例如酒店管理系统,里面管理着所有的业务实体,酒店实体自然是酒店业务在代码中的映射。我们常常会接到一个类似的需求,需要为菜单中包含宫保鸡丁的酒店标识为上海味道,前台可以基于这个标识筛选出符合期望的酒店。 很糟糕,这是一个标准的死亡陷阱,程序员先做了第一件事情,为酒店增加了一个属性叫做上海味道,对应的关系表也多一个字段。第二件事,必然的会修改所有可以触发该字段变更的地方加入新逻辑,若这是一个复杂的系统,必然痛苦不已。 所有初创公司的研发团队都消耗在了一些无用的事情之上,很快产生边际效应,他们已经无法应付真正的新品类拓展,光是打补丁便已经停不下来。那么到底是哪里错了呢? 我要否定的就是这两件事,它们是不对的,首先第一点,我想先解释一个问题,什么是业务?…

关系型数据库使用中的误区系列:数据的价值

数据库这东西说起来真是一发不可收拾,其实本来只想写一篇文章总结,未曾想到写完第一节就超长了,也好,直接上一个系列吧! 正如前文所说ANSI SQL真是一种功能性极强的DSL,如同打架必备的折椅,睡觉需要的床,踢球要的足球一样,我认为他是当下最适合通过描述过程筛选数据的语言,但注意我说的是过程!例如:我要筛选库存红色的苹果,筛选价格从高到低的订单且只要100条,诸如此类。 但我们也常在反思对于过程的精确描述究竟是为了什么?这个查询的背后初衷是什么?我的观点是,我们描述了那么多的过程不就是为了得到预期的结果吗?我们为什么不能直接描述结果,让把其他的事情交给计算机来做呢? 每个小伙子在追GF的过程中包含了吃饭,看电影,打LOL等等过程,所有的这些,都是为了让对方成为你的女朋友这一结果,而且常常为了达到结果你会动态调整你的过程,痛并快乐着。万幸的是,在计算机的世界里不用大费周章,你没有痛,只要你能将结果准确的描述出来,那么程序便会为你实现结果。 试想一下,描述一句“我需要一个吃素菜的便宜的,而且我邀请朋友都喜欢的饭店”,计算机呈现的结果便会是你需要的那样,那岂不是更好。真心希望各位读者读到此处,从DSL角度,过程描述和结果描述角度,能带来你一点对于编程思想的畅想,我们频繁的使用SQL编程到底是为了什么?有没有可以让计算机学习之后,告诉我结果的技术呢?请带着想法关注本系列,关注budaoxing这个订阅号。 《关系型数据库使用中的误区系列:…

关系型数据库使用中的误区系列:最大误区

开了订阅号,看到序言的PV数往上跳过了自己的期望值,尤其看到订阅者中男女比例已经达到二比一时,小小的脸红之余有了一点小小的膨胀。SO笔耕不能停!虚心接受大家意见,调整了下段落布局,希望大家喜欢。 这次,我们来简单说说关系型数据库,我喜欢使用大量的引用和比喻来阐述观点,文章会很碎同时也会比较发散,希望能为以后和之前的文章承上启下。最后我也深信一点,能够百度到的“知识”不是“知识",所以我不是百度的搬运工。 写SQL肯定是一种编程,准确的说是DSL(领域特定语言)编程,ruby之父松本行弘在《代码的未来》一书中用了大量的文字描述这个话题,非常引起我的共鸣,因为我常反思未来是否在业务描述中会有一种DSL可以描述特定业务,那会有多动态,有多抽象,或者这是唯一正确的道路?我想在本文埋下一个伏笔,让大家牵挂着这个问题!这里我最想说的是,主流IT媒体有这样一种观点,“21世纪人人都要学会编程”,我很赞同,但我要补充的说,“21世纪人人都要学会领域特定语言编程”,而不是人人都在写JAVA。 关系型数据库RDBMS的使用往往陷入“误区”,我仔细分析了下,最大的误区在于场景选择!!你需要的是OLTP还是OLAP,这个误区在当下弥漫,99%的中国互联网企业做的架构有问题,那原因是什么呢?…