电子商务的交易记录，数据库怎么设计

首先来说对于这种场景有两种设计方法，这两种方法都能够满足扩展性要求

1. 把原有的横表转化为纵表存储属性，即

产品表：（product_id, product_name, product_class)

产品属性表：(product_id, property_id , property_name , property_value)

2. 保持原有横表设计思路，但是d性字段含义单独元数据表存储

产品表：（product_id, product_name, product_class, prop1, prop2, .... propn)

产品属性含义元数据表

(product_class , prop1_name ,prop2_name, ..... propn_name)

对于两种设计方法，个人理解为

a. 对于首页打开就必须要能够快速查询出来的属性，而且这些属性本身各类产品差异不大。而对于差异大的属性基本都是针对特定一个产品查询。可以采用方案1来做。

b. 首页显示产品列表时候就存在要显示出不同产品属性情况，采用方案2来做。当我们处理的是一个product list的时候，由于存在数据表本身的关联场景，用方案1会比麻烦，也影响性能。

没有用的，

1、微信支付交易单号相当于数据库中从在的id账号，只是一个自动生成交易的序列号，没有任何作用；

2、微信支付交易单号，不能用来查询数据库也不能用来调取数据库信息，根不能知道支付和支付商家的信息，因此不会出现交易后信息被泄密的现象；

3、交易单上面的数字和账号都是绝对保密的，而且数据存储在交易完成结算后商家信息则会被删除，不会存在信息泄露等现象内容发生。

---