注释和别名，是结构文档的一部分

公开落地里有一个很土的观察：给核心字段补业务注释，准确率会明显上升。不是因为注释有魔力，是因为口头词终于有地方挂。个人能做的，就是把注释、别名、示例值写全。

注释写计算，不写感想

「销售额」不如「已支付金额，含税，未扣退」。

别名表单独放

GMV、流水、成交额指向同一列还是不同列，写在别名表，不要写在字段名里。

示例值比类型更有用

status: paid / cancelled / refunded。有例子，WHERE 才写得下去。

一次完整的问法可以先写成下面这样：

给 pay_amount 补一条人能读的注释，并在提问里只用注释里的名字。

落到语句上，草稿常常是：

COMMENT ON COLUMN orders.pay_amount IS '已支付金额，含税，未扣退；单位元；取消单为 0';

注释是写给人的结构。结构只活在 information_schema 里时，问数只能靠猜。

结构是地图，不是附录

公开实现文章把列出表、描述字段、抽样行、再执行写成四件工具。工具顺序不能倒。执行放第一位，等于闭眼过马路。

结构链接的失败，十之八九不是语法。是找错表、找错列、找错枚举值。注释、别名、示例值，是地图上的注记。注记质量决定问数上限。有人只补三十个核心字段的含义，可用程度就明显上升。这是最不时髦、也最管用的工作。

语义层是把指标、维度、关联路径写成中间层。个人没有引擎时，用字典和卡片冒充。没有这一层，每次提问都在重新发明销售额。宽表好问、星型好管，选边可以，口径必须唯一。

读完这一辑可以做什么

给十个核心字段写注释：时间、金额、状态、用户、地区、类目，外加四个你会用到的。注释里写计算、单位、示例值。写完再去问数，少猜一轮。

注释写计算和单位。写感想的注释，等于没写。