我个人觉得，数据库中的最终形态应该来这样看，需求>=性能>实现方式。

我把你说的“考虑程序排查”归类到实现方式里面去了，不论什么时候需求都是大于一切，首先得先有需求再有这个项目让你去做，当然还要考虑到实际当中的牺牲，可能需求实现后性能不太靠谱就需要牺牲一些需求来达标性能，这是互补的，最后考虑的才是实现的方式怎么更nice。当然如果实现更方便但性能差别不大的话，还是更注重实现好一些，毕竟这东西需要人来做，人来维护……

上面的2种做法最后的目的是相同的，如果需求没有特殊的要求（db就得这么存！）的话，要考虑的就是性能问题，没说前提条件，没说环境因素，那么我们看第二种做法的性能可能要好于第一种，因为它就是从db拿了数据存一下，第一种还要改完再存，这不太好。但第一种看上去可能更通用一些，有可能第二种事先存的东西太有针对性或太简单了，不如第一种那么通用。

其实说了这么多你应该明白，项目中什么是重要的，考虑程序排查这个可以把它往后面放一放。

再说个例子，记得之前有个项目非常考验性能（比如每秒处理多少之类的），优化了一段时间后还差点能达标，最后就不得不把程序处理时的一些log拿掉（事实证明log比较费时间，这没有必要），加这些log就是为了更方便排查问题，但它不能影响到我们关注的性能。