-
buo4 技术教程组 用户
业务同学想改一条数据，你说"我写个 SQL"；他们说想看个表，你导出一份 Excel 发过去。然后他们改完再发回来，你再导进去。
NocoDB 的做法是：别搬数据，给现有数据库套一层表格界面。
研发和业务之间那道墙
数据存在 MySQL / PostgreSQL 里，但能用它的人只有会写 SQL 的那几个。于是流程变成：
- 业务提需求 → 研发写查询 → 导出结果
- 业务改数据 → 发回给研发 → 研发写 UPDATE
- 每次改动都要排期，哪怕只是改一个状态字段
问题的本质不是"没有系统"，而是数据库缺少一个给人用的界面。
NocoDB 怎么用
不搬数据，只加界面。 直接连接你现有的数据库，数据仍然留在原库里，NocoDB 只是提供一层可视化。这一点很关键——不用做数据迁移，也不会产生两份不一致的数据。
表格 / 看板 / 表单视图。 同一份数据可以切换视图：表格用来查改、看板用来看状态、表单可以给外部填写。
字段类型可配置。 文本、数字、单选、多选、附件、关联表、公式列，常见的都覆盖。
权限与共享。 可以按视图设置访问范围，生成只读或可编辑的分享链接，给外部协作方用也方便。
自动生成 API。 建好表之后 REST API 就有了，其他系统可以直接读写，不用额外开发接口。
什么时候该用，什么时候不该用
| 场景 | 是否合适 |
|---|---|
| 业务人员自助查改数据 | 非常适合 |
| 轻量内部管理系统 | 适合 |
| 复杂业务流程与审批 | 不合适，需另配 |
| 高并发交易系统 | 不合适 |
边界要清楚：NocoDB 解决的是"让人能直接操作数据"，不是"搭建业务系统"。一旦涉及审批流、复杂的业务校验、并发控制，就该交给正经的后端去做。
三步接入
- 部署 — Docker 一条命令，或者先用官方云服务快速体验。
- 连库 — 填数据库连接信息，选择要展示哪几张表。
- 配视图 — 调整字段显示、加筛选、设权限，然后生成分享链接或 API。
一点建议
只暴露该暴露的表。 不是所有表都适合放进表格界面，尤其涉及敏感字段和核心业务表的，建议单独建视图并限制字段。
权限先收紧再放开。 默认给只读，确认确实需要编辑再加写权限。直接改生产数据的风险，比想象中大。
对"让业务自己查改数据"这个具体需求来说，NocoDB 的投入产出比相当高——半天就能上线，之后研发就不用再接这类小需求了。