数据库设计是"后期成本"的主要来源。下面三条规则，前三年的项目里踩中的频率最高，补救代价也最大。
一、状态不要用"删除"表达
物理删除会带来一连串问题：报表口径对不上（历史金额凭空少了）、出了问题查不到、误删无法还原。正确做法是软删除 + 状态字段。
| 做法 | 后果 |
|---|---|
| 直接 DELETE 掉记录 | 报表数字变了，历史追溯断档，误删不可恢复 |
| 加 isdel 标记 + 回收站 | 列表隐藏、统计排除，但可还原、可追溯 |
| 用状态字段表达业务阶段 | 草稿/已提交/已作废各有语义，报表能按状态分口径 |
二、金额与数量要有明确精度
- 金额用定点数（DECIMAL），不要用浮点数——浮点数会出现 0.1+0.2≠0.3 这类误差，对账时非常难查
- 统一小数位：金额 2 位、单价可 4 位、数量按业务定，并写进字段说明
- 明确"是否含税""是否是原币"，多币种要拆成"金额 + 币种 + 汇率"三个字段
- 四舍五入规则只在一个地方实现，不要每个报表各写一遍
一个真实教训：某系统把金额存成浮点数，两年后财务发现全年对账差 37 元——不是算错，是每一笔的小数误差累积。改起来要动全库数据。
三、关键动作要留痕
留痕不是"记个日志文件"，而是在数据库里留下谁也改不掉的操作记录。至少要记：谁、什么时候、对哪条数据、改前是什么、改后是什么。
- 登录、登出（含失败尝试）
- 新增、修改、删除（含软删除与还原）
- 审批、驳回、作废等状态变更
- 导出与批量导入
- 权限与角色变更
四、三条铁律对照表
| 铁律 | 一句话判据 | 违反后的典型症状 |
|---|---|---|
| 状态不用删除表达 | 删掉一条记录，上个月的报表数字会不会变？会变就错了 | 月度报表数字每查一次不一样 |
| 金额明确精度 | 两个报表算出的合计差几分钱吗？ | 对账永远差一点点，查不清 |
| 关键动作留痕 | 出了问题是"谁改的"还是"不知道"？ | 数据被改动，找不到责任人 |
这三条在设计评审阶段多花两小时，能省掉后期几个月的返工。