开发过程中，数据的最终储存是否需要考虑程序排查问题的方便性
举一个简单的例子：
现在淘宝，一号店等一系列电商都有自己的开放平台。我现在的程序调用淘宝开放平台的上传商品接口来上传商品。并且把上传的实体通过JSON格式存储在数据库中。那么这里就会出现两种储存结果：
- 存储的是一个中间的状态。当程序运行的时候,需要把实体从数据库中取出来，然后经过一系列的初始话操作来对实体进行处理以后。然后再调用接口上传。
- 存储的是一个最终的状态。程序运行的时候，只需要把实体直接取出来，不需要经过任何其它的操作，就可以直接上传
这两种方式，当上传接口返回错误信息的时候。第一种方式重现需要将数据库里面的数据取出来，然后跑测试用例，而第二种方式将数据取出来,直接通过main方法就可以重现。其实这两种方法的复杂程度是差不多的，但是第二种查起来可能会更加快。因为不用去跑测试用例(测试用例每跑一次加载配置项的时间让人不能忍)，这里会节省一点时间。
问题： 数据库存储的数据的最终形态究竟应该是怎么样的呢？像上面第一种和第二种方式哪种比较优？而这个最终形态是否需要考虑程序排查问题的方便性？
fukona
10 years ago
Answers
我个人觉得，数据库中的最终形态应该来这样看，需求>=性能>实现方式。
我把你说的“考虑程序排查”归类到实现方式里面去了，不论什么时候需求都是大于一切，首先得先有需求再有这个项目让你去做，当然还要考虑到实际当中的牺牲，可能需求实现后性能不太靠谱就需要牺牲一些需求来达标性能，这是互补的，最后考虑的才是实现的方式怎么更nice。当然如果实现更方便但性能差别不大的话，还是更注重实现好一些，毕竟这东西需要人来做，人来维护……
上面的2种做法最后的目的是相同的，如果需求没有特殊的要求（db就得这么存！）的话，要考虑的就是性能问题，没说前提条件，没说环境因素，那么我们看第二种做法的性能可能要好于第一种，因为它就是从db拿了数据存一下，第一种还要改完再存，这不太好。但第一种看上去可能更通用一些，有可能第二种事先存的东西太有针对性或太简单了，不如第一种那么通用。
其实说了这么多你应该明白，项目中什么是重要的，考虑程序排查这个可以把它往后面放一放。
再说个例子，记得之前有个项目非常考验性能（比如每秒处理多少之类的），优化了一段时间后还差点能达标，最后就不得不把程序处理时的一些log拿掉（事实证明log比较费时间，这没有必要），加这些log就是为了更方便排查问题，但它不能影响到我们关注的性能。
美希命社长
answered 10 years ago
