先说一个我几年前遇到的问题，开发找到我问一个场景执行起来很慢。我看了一下是查看余额，后台其实看得到SQL的。
画外音：这里由衷感谢能从后台直接看SQL是多么幸福。JVM上OOM了，你最多看到java的方法，但是里面写了什么鬼玩意你不知道。就算知道了那要费半天劲才能找到他内部调用关系什么的。其实质最终还是SQL。hadoop当年就是因为没有SQL才不得不搞出Hive，而Hive又太慢（中间又和磁盘交互的步骤）才又出来了简单粗暴的Impala。现在连es都支持SQL，所以说SQL是数据库的明珠。
回归正题，这个余额他们实现是把所有用户的流水sum一下。支出是负数，收入是正数。这样算下来就是余额。逻辑对不对？对，实现傻不傻？傻。有人说你不能好好说吗？我这个够客气的了，你这个拿到外面，别人说你的还难听。要想成长就接受这个。我就是被蹂躏才成长的。
其实不仅仅是余额，这一类场景，比如库存，是不是也是这样？我们不要每个都去实时计算，这种在计入流水的时候有另外一个表，专门记录余额和库存就行。放在一个事务中，保证不会错然后去读这个余额和库存的表，那效果，和redis是一样的。
上周一个朋友他们用图数据库，找到我感慨说，通过用这个让他们明白了很多。很多时候是需求没说清楚，而他们走了不少弯路，但是现在少了。为什么？这是今天要说的，作为业务部门他们自己学会导数据了。这还不算，然后他们学会了SQL，这里的SQL不是select，图数据库的SQL是match那种。业务人员根据数据自己写，看执行结果，哪里不对了或者没有达到预期，他们最清楚。然后看是数据问题还是查询问题。这样少了很多和开发扯皮的情况，避免了相互撕。而开发要做的就是把他们写好的SQL嵌入到应用中去，大家都比较高效。不过开发的价值就是比较低了，真正的码农，连SQL都是业务人员自己写的，比较容易替代。他还提到做到最后发现很多都是设计问题，表设计，关系设计。说到这里我也是这样认为的。俺也一样。
我见过太多了表、视图设计的惨不忍睹，不忍直视。原由是开发设计的，这里不是说开发不能设计。我在陆金所遇到过淘宝出来的开发，那个设计真的好。他是站在数据库的角度设计的，最后又简洁又高效。但是大部分开发是面向对象设计的，而数据库是面向物理学和数学构成的，不在一个频道上。能调和吗？也可以，以后专题讲吧。最后他们说他们打算重新推翻以前的设计，重新来了。我由衷佩服他们的思想。其实很多时候有人说你帮助优化一下。我一看，这是能优化的玩意吗？还不如重来呢。黄宏的小品装修中说的，这种破相等于整容啊。在设计糟糕的情况下，一切优化都显得苍白无力。
需求没错人家要个余额，库存，但是谁让你这样sum实现了？遇到好的业务和产品就像刚才说的朋友人家给你设计，实现。你嵌入一下就行。遇到一般的就说。这个需求很简单，怎么实现我不管。
就一句“字要大”，你能解决吗？
