一次失败的模型设计的总结

数据结构：

首先有一张主表，就是交易表，记录了本次交易的一些基本信息。交易编号等，其中包含了商品清单。一个交易可以有很多条清单，因为我目前系统里面包含的清单数据量很大，可能有上千条，这直接影响了我的设计原则。

需求

在交易的进行中，现在要求可以对价格可以改变，也就是说通俗来说的讨价还价。以最后谈好的价格为最终价格，但是要求记录每一次谈价的历史，这样就可以方便回顾。展现整个谈价的过程。

方案：

• 1 （快照）最简单，就是增加两张历史表，数据结果和原来分别对应，只是增加一个关联主键。记录每一次谈价的数据，然后更新主表的数据。但这种方案一开始就被否决，因数数据量太大了。如果有一千条单据，那么每一次谈价都要至少有一千条记录产生，而其实客户可能只针对其中一条商品的价格进行了改变，这样是无意义的浪费。
• 2 （变更） 因此也就催生了第二种设计。第二种设计在宏观上做到了记录最小的数据，但是却在实现上产生了很大的难度。（这是在我们真正编码的时候才发现根本很多情况没有考虑到，二推倒重来在时间上也已经来不及了。）

方案一的模型很简单，暂且不谈。
我们先来看看方案二，以及问题到底出现在哪里了。

仔细看，第一个字段记录了改变的主表id ,第二个字段代表历史的轮次，第三个字段代表改变的类型，（分为主表和清单表），第四个字段表示更改的字段，例如更改的是清单的价格，那么存入的就是picrce,字符串。第四个一般存入清单的id，第五个存入的是原始值，依次是期望值，和返回值。

先说好处，不说实现难易程度。

一切以实际数据说话。
那么我们先假对编号为10001的交易单据进行更改，这条单据里包含五种商品，分别是abcde，假如第一次针对其中a的价格进行了改变，那么记录可能就会是这样：

count	orival	wishval	wishval	changeId
1	10	8	6	a

现在来看这样确实很好，因为只会记录改变的数值。

count	orival	wishval	wishval	changeId
1	10	8	6	a
2	20	15	18	b
3	100	90	90	c
4	6	5	5.5	a
5	18	15	16	b
5	90	80	86	c

除此之外，我们还要考虑到一点就是，客户在每一次沟通好之后都可能会以当前好的价格进行交易，那么为此现在做的就是每一次插入改变的历史记录以后，同时update 两张主表，也就是说主表是实时更新的。

那么问题来了，现在客户想要知道第二轮谈价格的时候的整个交易情况，我们要去做怎样的判断？

我们看到，第二轮针对的是商品b，我们想当然的把b的价格改变查找到，然后就可以万事大吉了。但是还是太年轻。

请注意，商品a,c 的价格都不正确

因为第二轮这两个商品的信息根本没有保存，但是后面却改变了，因此主单的价格也更改了，所以这样查出来的结果是错误的。

而当我们发现这个严重的问题时候，距离上线还只有两天。推倒重来已经来不及了，只有研究破解之道。

那么第二轮ac 正确价格到底怎么找到呢？我们把所有历史都找到就好了。依次找最近的关于a的更改，一看是在第四轮，那么第四轮里面的orivaL 就是我们想要的了。

好吧，就是这么坑爹。

接下来为了捋顺这个别扭无比的逻辑，我们的代码嵌套了无数的循环和增加了很多种我们没有想到的判断。

最后测试的时候还是一堆bug。

这就是最开始设计的时候没有想到这个结果的原因。

以此为戒吧。