数据结构如何定义以及清理 例如订单的附带商品信息数据

Question

订单内商品数据应该怎么保存

方案一
在订单创建的时候直接把商品数据保存在订单里面，作为订单的一个附属字段
这样子后续修改商品，不会对已经在订单内的商品任何影响
问题：如果商品修改不频繁的情况下，会大量增加订单数据的大小，同一个商品下10单，10个单里面都有商品数据（特别是需求显示商品的字段较多时，比如规格，产地，单位等等等等)
方案二
在订单创建的时候，对商品生成一个快照存在一个商品快照表中（同一个商品可含多个快照，订单创建时判断商品快照是否为最新，最新则不新生成快照），订单内存储商品快照ID，显示订单商品时，用ID去取商品快照显示
这样子后续修改商品，不会对已经在订单内的商品任何影响，
问题：比如订单只保存最近一年，一年以前订单自动归档，那商品快照表就需要单独处理判断商品的快照是否该归档，如果商品快照不定期归档，数据量会无限变大
方案三
创建订单直接保存商品ID，显示商品的时候在去商品表里查询商品
这样子最节省空间
问题：如果商品删除或者修改了之后，订单也会跟着变

请问大家这样子的数据究竟怎么存合适，方便清理归档，快速查询，节省空间。

Answer 1

最开始用的方案三，发现有问题，然后改的联合使用你的方案一和方案二

订单里面存产品id和版本号还有其他关键信息，如商品名称、价格、供应商等。(查询的时候不用连表)

然后商品还有一个带版本号的历史表，可以根据订单里的产品id和版本号关联查询到。

Answer 2

使用方案二比较好，其中快照的字段可以不完全照办商品表的 -- 快照一般不需要筛选只是用来查看，可以把多个相关字段合并成一个字段。

Answer 3

求大神们赐教，这个问题困扰我好久了，一直拿不定主义到底用何种方式存储。要考虑到以后订单量超大的情况，所以就怕以后需要重写，不敢随便定义。

Answer 4

Just my 2 cents.

尽管不熟悉此类业务，但是否可以考虑在商品表中保存变动信息。

attr_history: [
{
attr: name,
value: value,
start: new Date(2016, 1, 1),
end: new Date(2016, 4, 1)
},
{
attr: name,
value: value,
start: new Date(2016, 1, 1),
end: new Date(2016, 4, 1)
}]

Answer 5

方案一：“10个单里面都有商品数据”，比如一个20160901版本的商品，有1000个人买了，没必要每个订单里面都存一下这个版本的商品数据，冗余过度
方案三：业务不合理的啊

方案二：其实就算不说订单这事，也需要保存一个商品的所有历史版本(快照)。
问题解决：商品快照可以采取一个定期归档的措施，归档可以采取转移至只读数据库等措施。另为了提高使用性能和使用时长，可以对商品快照进行分表，比如201609一个商品快照表，201610一个，具体看你们的业务量和具体的业务需求了。