代码片段：订单快照的属性结构

\application\api\service\Order.php中：

//订单快照：保存订单当前的状态。如，订单里商品价格、收货地址发生变化了，就成了快照。

private function snapOrder($status)

{

$snap = [

'orderPrice' => 0,

'totalCount' => 0,

//pStatus：保存订单里的某一个详细信息。

'pStatus' => [],

'snapAddress' => null,

'snapName' => '',

'snapImg' => ''

];

$snap['orderPrice'] = $status['orderPrice'];

$snap['totalCount'] = $status['totalCount'];

$snap['pStatus'] = $status['pStatusArray'];

//把数组存入数据库,把数组系列化成json字符串。把对象作为数据库某一个表的某一个字段，其实不是太好，维护困难。想存储一个对象，有两个常见办法：第一，把对象下面的每一个属性，拆开，再做一张表。第二（最好！），不选择关系型数据库，而是选择文档型数据库，如mongodb。中小型项目中，nosql数据库多半作为对关系型数据库的补充。

$snap['snapAddress'] = json_encode($this->getUserAddress());

$snap['snapName'] = $this->products[0]['name'];

$snap['snapImg'] = $this->products[0]['main_img_url'];

if (count($this->products) > 1)

{

$snap['snapName'] .= '等';

}

return $snap;

}

注记：

1、不要在一个方法里，一口气写完所有业务逻辑，应该巧妙地多封装成几个方法。这样可以简化主方法业务调用流程。方法是嵌套的。一般地，一个方法不建议超过50行。

2、当业务比较复杂时，可以提炼出几个主干和模型。模型是OOP思想的延伸，可以帮助理清业务思路。模型不仅仅是为了写代码，更是构建、拆分业务的思维方式。虽然现在做软件开发，基于时间关系，很少画UML建模。如，几个主要的模型：订单order、商品product、收货人address。

3、快照解决动态变化的问题，还有利于加快数据库的查询。一般地，写的速度远远是要大于读。为了加快数据库访问速度，会做读写分离。

4、结合业务，才能设计出较好的数据表结构。