数据属于自己，不该只是一句口号

先划清无代码的边界

表格视图、表单和自动化很适合快速验证流程，但它们不是数据策略。订单、权限、附件和审计记录仍然需要明确的字段、关系与生命周期。供应商界面可以更换，业务事实不应被锁在某个按钮里。

数据库是协作的契约

以客户与发票为例，客户编号必须稳定，发票应引用编号而不是复制客户名称；删除客户时还要决定是阻止删除还是保留历史。把这些规则写进 schema、唯一约束和迁移，团队才能在换工具后继续工作。

Teable 的开源实现展示了把数据库能力做成可协作表格产品的路径。它的公开仓库可用于理解表、字段、视图和权限如何组合；使用者仍应阅读许可证与部署文档，选择适合自己的托管方式。

-- 一个可迁移的最小约束
CREATE TABLE invoices (
  id text PRIMARY KEY,
  customer_id text NOT NULL REFERENCES customers(id),
  issued_at timestamptz NOT NULL
);

所有权意味着可导出、可恢复

至少准备定期导出、恢复演练和字段字典。导出不只是 CSV：关系、附件、时区和删除语义也要能重建。先在临时环境恢复一份，再把校验行数与关键外键作为发布检查。

从 undb 看到的迁移教训

undb 的公开仓库已经归档，当前说明指向 Teable。它提醒我们：项目会转向，数据却要继续存在。把 undb 当作可阅读的历史实现可以理解选择，但不要把归档仓库当作仍在维护的服务或安全承诺。

何时不该自己托管

如果团队没有备份、升级和权限维护能力，托管服务可能更稳妥；这不等于放弃所有权。合同中的导出格式、保留期、删除流程和退出窗口，和代码中的 schema 一样重要。