java - 开发过程中，数据的最终储存是否需要考虑程序排查问题的方便性

Question

举一个简单的例子：

现在淘宝，一号店等一系列电商都有自己的开放平台。我现在的程序调用淘宝开放平台的上传商品接口来上传商品。并且把上传的实体通过JSON格式存储在数据库中。那么这里就会出现两种储存结果：

• 存储的是一个中间的状态。当程序运行的时候,需要把实体从数据库中取出来，然后经过一系列的初始话操作来对实体进行处理以后。然后再调用接口上传。
• 存储的是一个最终的状态。程序运行的时候，只需要把实体直接取出来，不需要经过任何其它的操作，就可以直接上传

这两种方式，当上传接口返回错误信息的时候。第一种方式重现需要将数据库里面的数据取出来，然后跑测试用例，而第二种方式将数据取出来,直接通过main方法就可以重现。其实这两种方法的复杂程度是差不多的，但是第二种查起来可能会更加快。因为不用去跑测试用例(测试用例每跑一次加载配置项的时间让人不能忍)，这里会节省一点时间。

问题：数据库存储的数据的最终形态究竟应该是怎么样的呢？像上面第一种和第二种方式哪种比较优？而这个最终形态是否需要考虑程序排查问题的方便性？

Answer 1

我個人覺得，資料庫中的最終形態應該來這樣看，需求>=效能>實作方式。

我把你說的「考慮程式排查」歸類到實現方式裡面去了，不論什麼時候需求都是大於一切，首先得先有需求再有這個項目讓你去做，當然還要考慮到實際當中的犧牲，可能需求實現後性能不太可靠就需要犧牲一些需求來達標性能，這是互補的，最後考慮的才是實現的方式怎麼更nice。當然如果實現更方便但性能差異不大的話，還是更注重實現好一些，畢竟這東西需要人來做，人來維護……

上面的2種做法最後的目的是相同的，如果需求沒有特殊的要求（db就得這麼存！）的話，要考慮的就是性能問題，沒說前提條件，沒說環境因素，那麼我們看第二種做法的效能可能比第一種，因為它就是從db拿了資料存一下，第一種還要改完再存，這不太好。但第一種看起來可能比較通用一些，有可能第二種事先存的東西太有針對性或太簡單了，不如第一種那麼通用。

其實說了這麼多你應該明白，專案中什麼是重要的，考慮程式排查這個可以把它往後面放一放。

再說個例子，記得之前有個項目非常考驗性能（比如每秒處理多少之類的），優化了一段時間後還差點能達標，最後就不得不把程序處理時的一些log拿掉（事實證明log比較花時間，這沒有必要），加這些log就是為了更方便排查問題，但它不能影響到我們關注的性能。