Notion 数据库设计指南：少字段、高复用、可协作
Notion 用久了，很多人的数据库都会变成“信息垃圾场”：字段越来越多，视图越来越乱，谁都不敢删，最后每个人都绕开系统自己记。你以为是工具问题，其实是设计逻辑出了偏差。
数据库失控的早期信号
- 同一个信息在 2 个以上字段里重复记录。
- 新成员不知道该填哪个字段，靠口头询问。
- 同类任务在多个数据库同时存在，状态冲突。
- 视图很多，但没有一个视图真正支持日常决策。
这些信号出现时，不要急着加自动化。先收敛模型，再谈效率。
最小可用模型：先保证 80% 价值
数据库设计第一原则：字段为决策服务，不为“记录完整”服务。对大多数内容团队，三个核心库就够了：
- 任务库：谁做、何时做、做到哪一步。
- 项目库：目标、阶段、风险、交付标准。
- 知识库：结论、来源、可复用模板。
每个库建议控制在 8 到 12 个字段。超过这个数量，不是不能用，而是维护成本会迅速上升。
关系与汇总怎么用，才不会把自己绕进去
Relation 和 Rollup 是 Notion 的核心能力，但也是最容易被滥用的功能。你应该先问一个问题：这个关联是否会改变决策？如果不会，就不要连。
关系字段不是“功能展示”，是“信息上下文最短路径”。
常见高价值关联有两个：项目 → 任务（看执行密度），文章 → 主题（看内容覆盖）。除此之外的复杂链路，先延后。
视图策略与权限：系统能不能被执行，关键在这里
同一数据库至少要有三个视图：执行视图（今天做什么）、管理视图（哪儿卡住了）、复盘视图（什么值得复用）。如果没有角色化视图，团队一定会各用各的。
权限也要最小化：编辑权限留给责任人，其他人以评论和查看为主。否则系统很快会出现无意覆盖与版本污染。
可持续迭代原则：删比加更重要
每两周做一次数据库复盘，重点看三件事：哪些字段没人填、哪些字段不影响决策、哪些字段经常填错。复盘后要敢删字段，不要只会加字段。
- 连续两周无数据的字段，默认进入删除候选。
- 无法定义填写标准的字段，先下线。
- 可由计算得出的字段，不手填。
真正好的系统，不是功能最多，而是团队最愿意长期使用。