目测引战帖

@whyou126 嗯，但看起来半路丢件的可能性挺大

@dhairoot 这个不好说呢，分布式解压也得看你有多少资源可以被用起来，是有闲置的资源吗，还是解压速度已经够好了只是达不到心理预期？

挺好的，我刚卖了几本书给多抓鱼，他们可以提现，有的时候就是想卖钱，他们也鼓励用余额支付，能再打折。

如果你只是想解压这些 zip 文件的话，多开几个进程或者线程，和 CPU 个数差不多，一个个解压就挺快吧？当然如果有很多资源可用，确实可以搞分布式解压，就行 mapreduce 一样？

在家 fix bug

我司手写复杂 SQL，但也不至于连 insert into 也是手写，对数据库操作有简单封装，主要是对结果进行封装：获取一行、获取一列、获取某行的某列、执行任意 SQL，如果有特别需要 insert into 也是手写，不使用 ORM，这样很直观，心里有底吧。

对结果简单封装后用起来和 ORM 差不多，比如获取一个订单：

```python
purchase = db().get('SELECT * FROM purchase WHERE id=%(purchase_id)s', purchase_id=123)
print(purchase.shopper_id)
print(purchase.sales_channel_id)
```
等等读取操作和用 object 的感觉一样，但如果要更新 purchase 则需要写 SQL：
```
db().execute('UPDATE purchase SET processed_at=CURRENT_TIMESTAMP WHERE id=%(purchase_id)s', purchase_id=123)
```

获取一些订单：
purchases = db().list('SELECT * FROM purchase WHERE created_at>=CURRENT_DATE')
for purchase in purchases:
print(purchase.id)

获取订单某个字段：
shopper_id = db().get_scalar('SELECT shopper_id FROM purchase WHERE id=%(purchase_id)s', purchase_id=123)

获取订单 ids：
purchase_ids = db().list_scalar('SELECT id FROM purchase WHERE created_at>=CURRENT_DATE')


对数据库的变动写 migration 脚本，按顺序部署时应用到数据库中。

开发环境中模块对表的读写有管理，不是某个模块想写哪就写哪，想读谁就读谁，但这个在生产环境不检查。