xiaochun41

库表设计方面的话题太大了，不过基本上可以从这几个方面考虑：
1. 字段命名，
2. 字段类型的选择
3. 数据模型的设计（业务对象如何存，存几张表，如何冗余）
4. 业务对象关联关系的设计（业务对象的关系怎么存等）
5. 索引的设计
6. 存储引擎的选择
7. 库表容量的规划（数据规模多大，增长趋势如何，是否考虑分库分表）
8. 团队的规范
9. 行业最佳实践

暂时想到这些

https://toolbelt.readthedocs.io/en/latest/uploading-data.html#streaming-multipart-data-encoder
参考下

exec，eval 可以了解下。

解决方案是 搞个大屏的墨水屏阅读器，效果还行，国内有不少厂家有类似产品。大部分是安卓系统。价格略高，可以权衡下。

@dwadewyp 我们只是在一个阶段这样做了，后来业务规模扩大了，就对服务进行了拆分（包括数据库），各个服务维护自己对应的数据库，对外只暴露 api 了。如果要这样做，应该考虑对 开发、测试及发布带来的问题，以及对应的解决方案。记得当时有个问题，比如发布时，都要先更新 model 。

似乎是需要一个好用的 shell 环境，比如 zsh + oh-my-zsh

这个取决于个人吧，13 年秋季的 256G 的 macbook pro，现在有 20G 空闲，偶尔也用虚拟机运行 win

几年前也遇到过这样的问题，当时有个简单的做法：把所有的 model 都抽离出来，单独形成了一个包。其他用的项目都引用这个包。

遇到过很多次这样的情况，基本上最后都是靠厂商提供的高防服务。