使用GORM的核心思路梳理
一个对象 = 一行数据
示例中的一个User对象，完整地对应到具体users表中的一行数据，让整个框架更加清晰明了。每当数据库增加了一列，就对应地在结构体中加一个字段。这里有两个注意点：
- 不要在核心结构体User中加入非表中的数据，如一些计算的中间值，引起二义性；
- gorm.Model可以提升编码效率（会减少重复编码），但会限制数据库表中字段的定义，慎用（个人更希望它能开放成一个接口）；
选择生效字段 = 核心结构体 + 字段数组
在 查询 和 更新 接口里，我推荐的使用方法是采用核心结构体User+一个fields的数组，前者保存具体的数据、也实现了结构体复用，后者则选择生效的字段。
这种风格代码和Google推荐的API风格非常像，可读性很棒。
- 这里还遗留了一个问题，就是fields数组里的字符串必须手输，可以考虑结合go generate自动生成这些fields的字符串常量，减少出错的概率。
缩短链式调用
GORM的主要风格是链式调用，类似于Builder设计模式、串联堆起一个SQL语句。这种调用方式扩展性很强，但会带来了一个很严重的问题：容易写出一个超长的链式调用，可维护成本大幅度提高。
所以，在我的推荐使用方式里，区分了两种场景：
- 简单场景 - 核心结构体 + 字段数组
- 复杂场景 - 原生SQL
聚焦微服务的场景
作为一个ORM工具，GORM要考虑兼容各种SQL语句，内部非常庞大的。但如今更多地是考虑微服务的场景，这就能抛开大量的历史包袱，实现得更加简洁。这里我简单列举三个不太推荐使用的SQL特性：
- 减少group by - 考虑将聚合字段再单独放在一个表中
- 抛弃join - 多表关联采用多次查询（先查A表，然后用In语句去B表查）、或做一定的字段冗余（即同时放在A、B两个表里）
- 抛弃子查询，将相关逻辑放在代码里
当然，真实业务研发过程中无法完全避免复杂SQL，我们只能有意识地减少引入复杂度。
避免引入非原生MySQL的特性
GORM除了常规的SQL功能，还提供了一些高级特性、模型关联、钩子等，非常炫酷。
但我不推荐大家在实际项目中使用这些特性。只有尽可能地保证这个框架简洁，才能保证代码后续的可维护性。
熟悉MySQL历史的朋友都知道，存储过程在以前相当一段时间都是很好的工具，但如今都倡导去存储过程。GORM的这些特性和存储过程有异曲同工之处：一个将业务逻辑放在了数据库，另一个则放到了ORM框架里，会导致后续的迁移成本变高。（这也是我不推荐使用 gorm.Model的重要原因。）
