SaaS 数据模型：从第一天就想清租户、权限和审计

开场：数据模型会决定后面能不能长

早期 SaaS 最容易先做页面。登录页、列表页、详情页、设置页很快能跑起来。但如果底层数据模型随手设计，后面会不断遇到麻烦：客户数据混在一起，权限不好加，状态无法追踪，审计补不回来，导出困难，迁移成本越来越高。

从 0 开始不需要过度架构，但有些基本数据边界必须尽早想清楚。因为 SaaS 服务的是多个客户的持续业务，一旦真实数据进来，很多错误就很难轻松改。

好的早期数据模型，不是复杂，而是边界清楚。

每张业务表都要知道属于谁

SaaS 多租户最基本的问题是：这条数据属于哪个客户？

无论你用什么技术栈，早期都应该明确租户标识。常见字段包括：

• account_id
• workspace_id
• tenant_id
• organization_id

名字不重要，语义要稳定。业务表里要能追踪数据归属，否则后续权限、导出、删除、账单和审计都会很痛苦。

例如：

不要依赖“当前登录用户”来推断所有数据归属。用户可能属于多个团队，团队可能有多个项目，项目可能有外部协作者。归属要在数据结构中明确存在。

用户和工作区要分开

很多早期产品把用户和客户账户混在一起：一个邮箱就是一个客户。个人工具可以这样，但 B2B SaaS 很快会遇到团队协作。

更稳妥的模型是：

• 用户：一个自然人或登录身份。
• 工作区：一个团队、组织或客户账户。
• 成员关系：用户在某个工作区里的角色。

这样可以支持：

• 一个用户加入多个团队。
• 一个团队邀请多个成员。
• 成员离职后移除权限。
• 工作区级别计费。
• 后续增加角色。

早期可以只有所有者和成员两个角色，但模型上最好留下成员关系这一层。

状态字段不要随便写字符串

业务状态是 SaaS 的核心。工单、订单、项目、任务、订阅、导入任务，都会有状态流转。

如果状态随便用字符串，后面很容易混乱：

• done
• finished
• complete
• closed
• ok

一开始就应该定义状态枚举和流转规则。

例如工单状态：

状态不是字段细节，而是业务流程。状态混乱，报表、提醒、权限和自动化都会受影响。

审计日志要先做最小版本

早期不一定要完整审计系统，但关键操作至少要能追踪。

建议记录：

• 谁做了操作。
• 对哪个工作区。
• 对哪个对象。
• 做了什么动作。
• 操作前后关键值。
• 操作时间。
• 请求来源或备注。

关键操作包括：

• 删除数据。
• 导出数据。
• 修改权限。
• 修改账单。
• 变更状态。
• 修改核心配置。

审计的价值不是平时看，而是出问题时能解释。客户问“谁删了这个项目”时，如果你完全查不到，会非常被动。

软删除和数据保留要有策略

早期直接物理删除最简单，但风险很高。客户误删、内部误操作、同步错误都可能造成不可恢复损失。

可以考虑：

• 核心业务对象使用软删除。
• 记录删除人和删除时间。
• 设置恢复窗口。
• 对无价值日志设置保留周期。
• 对客户取消后的数据保留规则做说明。

不是所有数据都要永久保存。关键是要有策略，而不是每张表随意处理。

数据保留还会影响成本、隐私和客户信任。越早明确，后面越容易管理。

导出能力要从模型设计开始

很多团队等客户要求导出时才发现，数据散在多张表里，状态含义不清，字段没有人能解释。

早期设计时就要想：

• 客户最关心哪些数据能导出？
• 导出的字段名是否能被业务人员理解？
• 导出是否按工作区隔离？
• 附件和关联数据怎么处理？
• 删除和归档数据是否包含？

导出不是临时功能，而是数据模型可解释性的测试。如果你自己都很难解释字段，客户更难信任。

迁移要可重复

早期数据模型一定会调整。不要害怕调整，但要让迁移可重复、可回滚、可记录。

最基本的做法：

• 每次结构变更有迁移脚本或明确记录。
• 不手工在生产库随便改字段。
• 重要迁移前备份。
• 迁移后做数据校验。
• 记录迁移时间和影响范围。

数据迁移失败比页面 bug 更严重。随着客户数据增加，迁移纪律会越来越重要。

常见误区

第一个误区，是觉得早期不用多租户设计。即使只有一个客户，也要知道数据属于谁。

第二个误区，是过度抽象。不要为了未来所有可能性设计复杂模型，只要把归属、成员、状态、审计这些底座打清楚。

第三个误区，是忽略业务语言。字段和状态要让团队能理解，不要只有开发者看得懂。

第四个误区，是没有数据删除和导出策略。客户一旦认真使用，就会问这些问题。

一个最小数据模型清单

从 0 做 SaaS，可以先确认：

• 是否有稳定的工作区或租户概念。
• 用户和工作区是否分离。
• 成员关系和角色是否明确。
• 每张业务表是否有归属字段。
• 核心状态是否有枚举和流转规则。
• 删除是否可追踪。
• 关键操作是否有审计。
• 关键数据是否能导出。
• 数据结构变更是否有迁移记录。

这些设计不会让产品第一天显得更炫，但会让产品在第 50 个客户、第 500 个客户时少还很多债。