这个围绕 DeepSeek、Cursor、Devbox、Sealos 展开的零代码实战项目第一篇文章没有急着生成登录页而是先把数据库设计定下来数据库实例跑在 Sealos 上可视化建模用 DBeaver建表 SQL 交给 DeepSeek 草拟再由 Cursor 沉淀归档。这篇内容适合两类人一类是刚接触 AI 辅助开发的零代码新手想搞清楚数据库设计到底要干哪些事另一类是把这套工具链用于实际项目开发、想少走弯路的人。看完你会发现零代码项目省掉的是手写代码的时间省不掉的是设计时的判断。1. 为什么零代码项目要把数据库设计放在第一步很多人拿到“用 AI 开发项目”的需求后第一反应是打开 Cursor 或者找 DeepSeek 直接说“帮我做一个二手交易平台”。这个思路不能说错但缺了一个关键前置条件AI 生成的页面和接口必须建立在“表结构已经确定”的基础上。如果连用户表、商品表、订单表都没想清楚AI 生成的列表页和详情页就是空中楼阁后面改起来会非常痛苦。1.1 这个系列整体要完成的事把标题里的工具串起来其实就是一条完整的零代码开发链路DeepSeek 负责对话式需求分析和 SQL 生成Cursor 负责编辑与文档沉淀Devbox 提供统一的云端开发环境Sealos 是部署底座数据库和应用都跑在上面DBeaver 则作为数据库可视化客户端连接、查表、画 ER 图。这篇是系列的第 1 期只解决“项目设计阶段的数据库设计”这一件事。也就是说我们先不聊前端页面也不聊后端接口而是把整个项目的数据地基打牢。你在这篇文章里会拿到三样东西一份完整的表结构设计方案、一套可以直接执行的建表 DDL、一个已经创建在 Sealos 上的空数据库实例以及 DBeaver 里的可视化校验结果。1.2 数据库先行的三个理由第一个理由是表结构就是产品需求的结构化表达。零代码不是没有代码而是把代码生成交给 AI。但 AI 不能替你决定“用户有哪些字段、订单和商品是什么关系”这些业务判断必须由人来完成。把数据库设计放在最前面本质上是逼着我们把需求想清楚。第二个理由是数据库是后续所有生成内容的契约。AI 在生成登录页时它需要知道用户表里是 phone 还是 email生成商品卡片时它需要知道价格字段是 decimal 还是 text生成订单列表时它需要知道状态字段的取值范围。表结构一旦定下来后面 Cursor 生成的前端页面、DeepSeek 补的接口逻辑都会围绕这套契约展开。第三个理由是数据库设计的返工成本最高也最容易被新手忽略。改一个按钮样式几分钟就好但改一张已经写入数据的表可能要写数据迁移脚本、处理历史数据、更新所有关联接口。相比之下花半天时间先把表设计好是整个项目里性价比最高的投入。1.3 零代码的边界在哪里需要先说明一点所谓的零代码不等于全程不碰代码。在这个流程里我们依然会执行 SQL、填写连接参数、确认字段类型只是这些环节被工具大幅简化了。比如 Sealos 把数据库安装和运维变成了浏览器里的点击操作DBeaver 把命令行 psql 的操作变成了图形界面DeepSeek 把写 DDL 变成了自然语言对话。所以更准确地说这套流程是“低代码量的 AI 辅助开发”。对零基础用户友好但前提是愿意理解一些数据库基础概念比如主键、索引、外键、字段类型。这些概念在下文都会用大白话解释清楚。2. 五个工具在数据库设计这关的分工这个系列的工具组合不是随便拼的每个工具都有明确的定位。在数据库设计这个阶段有的工具要深度参与有的可以先放在一边但整体图景得先看清楚否则后面衔接时会很混乱。2.1 一张表看清五个工具的角色工具环节定位数据库设计阶段做的事DeepSeek对话式 AI 生成引擎根据业务描述生成表结构草稿、建表 DDL、字段审查建议CursorAI 原生编辑器沉淀设计文档、管理 DDL 文件后续开发时加载数据契约Devbox云端开发环境本阶段暂不启动后续写接口、跑脚本时提供统一环境Sealos云底座/应用托管一键创建 PostgreSQL/MySQL 实例提供稳定的连接地址DBeaver数据库可视化客户端连接云端实例查看表结构、编辑数据、生成 ER 图、执行 DDL2.2 为什么数据库实例放在 Sealos 而不是本地不少人的第一反应是“直接在本地装个 MySQL 不就行了”。对于纯学习目的本地安装没问题但放到真实项目链路里Sealos 有几个明显优势。第一Sealos 在浏览器里点几下就能创建一个独立数据库实例不需要本地安装、配置环境变量、处理各种依赖。零代码项目面向的是不想折腾环境的人这一点价值很大。第二Sealos 给的是固定公网连接地址后续应用部署在同一个云环境里通过内网或公网访问都很方便不用像本地数据库那样做内网穿透。第三数据库生命周期可以按需管理测试完直接删掉实例不会污染本机也不会出现“在我机器上是好的”这种环境问题。2.3 为什么可视化客户端选 DBeaver市面上数据库客户端不少Navicat 也很好用但它是付费软件。DataGrip 也要授权。而 DBeaver Community 版完全免费、跨平台、支持几乎所有主流数据库而且自带 ER 图功能。对零代码项目来说能用免费工具解决的需求没必要掏钱。实际操作中你会发现DBeaver 的“元数据查看”“SQL 终端”“ER 图”三个功能刚好覆盖数据库设计的三个关键动作看表结构是否正确、执行建表脚本、验证表关系是否合理。这个组合对新手很友好。3. 从需求到表结构把二手交易平台拆成一张张关系表工具选好了接下来进入核心环节把业务需求翻译成表结构。为了讲得具体我拿一个内部叫“模拟项目X”的二手闲置交易平台作为例子。这是一个典型的极简电商场景表不多但覆盖了零代码项目里 90% 的设计要点。3.1 从使用场景里梳理实体与关系在做任何设计之前先把用户故事列出来。这个平台的典型使用流程大致有九条用户注册登录用户发布闲置商品商品属于某个分类用户浏览和搜索商品买家下单购买买家填写收货地址订单状态流转买家确认收货后评价管理员处理违规内容。从这些场景里能提炼出九张核心表用户表、商品分类表、商品表、商品图片表、订单表、订单项表、收货地址表、收藏表、评价表。额外加一张管理员操作日志表用于后台审计。实体关系用文字描述是这样的用户和商品一对多一个用户能发布多个商品。分类和商品一对多一个分类下挂着多个商品。用户和商品多对多通过“收藏表”记录一个用户收藏多个商品一个商品被多个用户收藏。用户和订单一对多一个用户产生多个订单。订单和商品多对多通过“订单项表”拆开一个订单包含多个商品一个商品出现在多个订单里。用户和地址一对多一个用户有多个收货地址。订单和地址在订单表里冗余保存一份地址快照避免地址修改后历史订单看不到当时信息。这个关系梳理过程非常关键它决定后面建表的骨架。如果关系没理清AI 生成再多 SQL 也是白搭。3.2 核心表字段设计原则表结构不能拍脑袋每一张表的字段都要能回答“这个字段存什么、为什么需要它、谁会用它查询”。以最核心的三张表为例。用户表设计的重点在登录标识和软删除字段类型说明idBIGINT 自增主键无业务含义的内部分主键phoneVARCHAR(20)加唯一索引作为登录账号nicknameVARCHAR(50)展示昵称password_hashVARCHAR(100)密码哈希值绝不能存明文avatar_urlVARCHAR(255)头像地址statusTINYINT0 正常 1 禁用is_deletedTINYINT软删除标志0 正常 1 已删除created_at / updated_atTIMESTAMPTZ创建与更新时间统一带时区商品表是信息量最大的一张表设计时要注意“商品状态”和“价格精度”字段类型说明idBIGINT 自增主键主键user_idBIGINT发布者加索引category_idBIGINT所属分类加索引titleVARCHAR(80)商品标题控制长度descriptionTEXT商品描述priceDECIMAL(10,2)售价禁止用 FLOAToriginal_priceDECIMAL(10,2)原价允许为空cover_urlVARCHAR(255)封面图地址product_statusTINYINT0 审核中 1 在售 2 已下架 3 已售出view_countINT浏览量created_at / updated_atTIMESTAMPTZ时间戳订单表则是整个设计里最需要谨慎的地方它关联买卖双方、商品和地址快照字段类型说明idBIGINT 自增主键内部主键order_noVARCHAR(32)业务单号唯一索引buyer_idBIGINT买家加索引seller_idBIGINT卖家加索引total_priceDECIMAL(10,2)订单总金额statusTINYINT0 待付款 1 待发货 2 待收货 3 已完成 4 已取消pay_time / ship_time / finish_timeTIMESTAMPTZ各阶段时间可空address_snapshotTEXT收货地址快照JSON 文本created_at / updated_atTIMESTAMPTZ时间戳订单项表要特别注意“商品快照”字段因为商品可能下架、改价历史订单必须保留当时的信息所以不能直接关联实时商品表来展示。评价表、地址表、收藏表的逻辑比较简单核心就是“哪张表关联哪张表、哪些字段要加唯一约束”。收藏表里对 (user_id, product_id) 建唯一索引防止同一用户重复收藏。3.3 字段类型、主键、索引与约束的取舍很多新手喜欢把字段全部设为 VARCHAR觉得什么都能存这其实是最危险的做法。字段类型是给数据设的“边界”边界越清晰后面出 bug 的概率越低。主键我统一选择 BIGINT 自增而不是 UUID。原因是自增主键占空间小、写入顺序好、对索引友好业务唯一标识则单独用业务字段加唯一索引比如 order_no、phone。如果你有非常强的分布式场景再考虑 UUID对零代码小项目来说不必。金额字段用 DECIMAL 而不是 FLOAT 或 DOUBLE。二进制浮点数存金额会产生精度误差比如 0.1 0.2 在浮点里不是一个精确值。如果涉及支付对账更稳妥的做法是直接用 BIGINT 存“分”展示时再除以 100。我在模拟项目X里为了可读性先用 DECIMAL(10,2)但如果你做的是涉及真实支付的系统我强烈建议改成“分”。外键的问题要专门说。数据库设计课会教你建物理外键但实战项目里物理外键有时候反而碍事。它会在删除和修改时产生强约束导致业务操作被数据库卡住尤其在迭代快的项目里。我的实践是小项目如果团队经验不足可以用物理外键先保证一致性但像模拟项目X这种灵活迭代的场景我更推荐用逻辑外键加索引由应用层保证关联完整性。时间字段统一用 TIMESTAMPTZ存储 UTC 时间展示时按本地时区转换。千万别用字符串存时间否则排序、比较、计算时间差都会变得无比痛苦。4. Sealos 上创建数据库实例浏览器里点出云数据库设计稿写完了下一步是让数据库真实存在。这一节是用 Sealos 创建 PostgreSQL 实例的完整过程。可以说这是我用过的最顺滑的数据库创建方式之一不需要命令行不需要安装包全程浏览器操作。4.1 创建实例的具体操作步骤第一步打开 Sealos 平台并登录。如果还没有账号先完成注册和基本的实名认证这一步是为了使用平台资源。第二步进入“数据库”模块。不同版本的 Sealos 界面入口名称可能略有差异但核心都是找“数据库”或“数据服务”相关的菜单项。第三步选择数据库引擎。我这次选的是 PostgreSQL原因很简单PostgreSQL 对复杂查询和 JSON 数据处理更友好而且后续配合 AI 生成 SQL 时语法规范更严格。如果你更熟悉 MySQL 8.0选 MySQL 也没问题流程完全一样。第四步填写实例配置。需要配置实例名称、数据库名称、用户名、密码然后选择 CPU、内存和存储容量。测试环境选最小规格就够了比如 1 核 1G、10G 存储等真正上线再扩容。不要把生产环境的规格直接拉满纯粹是浪费钱。第五步设置网络访问策略。这一步容易被忽略。如果需要在本地用 DBeaver 连接就要开启公网访问或者是配置白名单把你的出口 IP 加进去。如果只允许后续应用从同一个 Sealos 环境内访问就可以不开公网。第六步确认创建等待实例状态变为 Running。创建时间一般在一两分钟内。创建完成后控制台会给出连接信息包括主机地址、端口、数据库名称、用户名。把这些信息复制保存好接下来的 DBeaver 连接要用。4.2 连接信息与 DATABASE_URL 的作用Sealos 提供的连接信息通常长这样主机pg-abc1234.api.sealos.io端口5432PostgreSQL 默认数据库名db_demo用户名demo_user密码你自己设置的密码把这些信息拼成 DATABASE_URL 就是postgres://demo_user:密码pg-abc1234.api.sealos.io:5432/db_demo这个 URL 后面会直接用到应用配置里无论是 Cursor 生成的代码还是以后部署的服务都需要它来连接数据库。所以在设计阶段就把它整理到项目的 README 里能省很多事。有一点要特别提醒Sealos 给的地址如果分内网和公网一定要看清楚自己当前在哪一端。DBeaver 跑在本地电脑上必须用公网地址如果后续服务部署在和数据库同一套 Sealos 环境里才适合用内网地址。我见过不少人拿内网地址在本地连接结果一直超时白白排查半小时。4.3 测试环境下的成本与生命周期管理Sealos 按资源实际使用计费测试实例挂着不关也会持续产生费用。虽然最小规格的成本很低但养成用完就关闭或删除实例的习惯仍然很重要。模拟项目X在测试阶段我习惯在一天开发结束后把数据库实例暂停第二天再启动。另外创建出来的只是一个空数据库实例表结构还没有。空实例可以先用 DBeaver 连接测试确认网络和权限没问题后再把第三章设计的建表 SQL 执行进去。这样“网络通不通”和“SQL 对不对”两个问题就能分开排查不会混在一起抓瞎。5. DBeaver 连接与 ER 图核验让表结构可见可查数据库实例已经跑在 Sealos 上了接下来要请出 DBeaver。这个工具相当于是数据库的“可视化驾驶舱”既能执行 SQL也能把表结构画成一张张关系图方便逐张核对设计。5.1 安装和环境准备DBeaver 分社区版和企业版免费功能完全够我们用。到官网下载对应操作系统的安装包装好后打开首页是一个数据库连接管理界面。第一次使用不需要配置什么跟着下一步走即可。有一个坑要先预告DBeaver 第一次连接 PostgreSQL 时会提示下载驱动如果网络环境不好可能下载失败。这种情况下要么在驱动下载设置里切换镜像源要么手动下载 PostgreSQL JDBC 驱动 jar 包放到 DBeaver 的驱动目录。这个坑我在第 7 节会详细展开。5.2 新建连接时的关键配置在 DBeaver 工具栏点“新建连接”选择 PostgreSQL然后填入 Sealos 提供的连接信息。主机、端口、数据库、用户名、密码逐一填好先别急着保存点一下“测试连接”。如果测试提示缺少驱动按提示下载即可。如果连接成功会显示数据库版本和服务器信息。这时候再点“连接设置”里的“驱动属性”把连接时区设为和数据库一致的时区避免查时间时出现偏移。如果是 MySQL 实例几个常见的连接属性也要提前准备好allowPublicKeyRetrievaltrueuseSSLfalse 或 sslModedisable。这两个属性解决的是 MySQL 8.0 认证方式和 SSL 连接的问题不设置可能直接报 “Public Key Retrieval is not allowed” 或 SSL 连接异常。连接串参数没法一概而论但思路是固定的先在 DBeaver 里把网络配置、认证配置、时区配置这三关过掉再谈后面的可视化。5.3 用 ER 图和 SQL 终端反向验证设计连接成功后左侧导航栏会列出所有 schema 和表。刚建好的数据库还是空的这时候有两种选择一是直接在 SQL 终端里执行建表 DDL二是先在 DBeaver 里手动建表再导出 SQL。我推荐前者因为我们已经有完整的设计稿直接用 SQL 终端批量执行最高效。SQL 终端在 DBeaver 顶部菜单可以打开把建表语句一条条粘进去执行。执行过程中如果报错错误信息会直接告诉你哪一行有问题改完重新执行即可。表建好后右键点击连接的“表”目录选择生成 ER 图。DBeaver 会自动把表之间的外键关系画出来。如果你的表设计里没有物理外键ER 图就不会显示连线这时候要回头检查一下逻辑外键有没有对应的索引索引是否在合理字段上。ER 图的价值在于它把“表结构设计稿”和“真实数据库”之间的落差直接暴露出来。比如发现某张表没有主键、某两个表之间应该有关联但没建索引、某些字段类型不对都可以在图上一眼看出来。这一步相当于给数据库设计做了一次体检。6. DeepSeek Cursor 生成和审核建表 SQL 的方法很多人以为 AI 写 SQL 就是一句话的事其实要把 SQL 写对、写规范提示词和审核流程比 SQL 本身更重要。这一节分享我在这套流程里沉淀下来的方法核心是“让 AI 先给方案再给代码最后交叉检查”。6.1 提示词不是聊天而是需求文档给 DeepSeek 的第一条提示词我会这样写你是资深 DBA。我在设计一个二手闲置交易平台核心流程包括用户注册登录、用户发布商品、商品分类、买家下单、订单状态流转、买家填写收货地址、买家确认收货后评价、收藏商品。 请先不要直接输出全部建表 SQL按以下顺序回答 1. 列出你建议的实体清单以及实体之间的关系。 2. 针对每个表列出关键字段及类型标注主键、唯一索引、普通索引。 3. 等我确认表结构后再一次性输出完整的 PostgreSQL 建表 DDL。 4. 要求金额字段用 decimal时间字段用 timestamptz主键用自增 bigint所有表都要有 created_at 和 updated_at软删除字段统一命名为 is_deleted。这个提示词有三个关键点。第一给了角色设定AI 回答会更专业。第二限制了输出节奏先出方案、确认后再出 SQL避免大量不可读的内容。第三写清了硬性约束比如金额类型、时间类型、主键策略AI 就不会自由发挥。如果你不告诉 AI 这些约束它很可能给你生成一个 UUID 主键、VARCHAR(255) 存所有字段、没有注释的表结构。不是它不懂是你没把需求表达清楚。6.2 AI 生成 SQL 后必须做的审查AI 生成的 SQL 依然需要人工复核。我在项目里固定了一张检查表每张表都要过一遍检查项期望结果主键有且为自增 BIGINT不包含业务含义唯一约束用户手机号、订单号等业务唯一字段有唯一索引金额字段DECIMAL 或 BIGINT绝不能是 FLOAT/DOUBLE时间字段统一 TIMESTAMPTZ有默认值 CURRENT_TIMESTAMP软删除统一命名 is_deleted所有业务表都有索引唯一索引 外键索引 高频查询字段索引不能全表加索引字符集UTF8/utf8mb4保证中文和表情符号正常复核方法也很简单把 AI 生成的 DDL 再贴回 DeepSeek让它以审计视角检查一遍。你会发现 AI 自己发现的问题往往很准比如漏了唯一索引、时间字段默认值缺失、某张表缺了软删除标志。这种“生成 审查”的循环比一个人埋头检查快得多。6.3 Cursor 里的落地习惯SQL 确认没问题后打开 Cursor把这个项目建好目录。我习惯在项目里建一个 docs 文件夹里面放两份文件schema.sql最终确认的建表 DDL作为代码库的一部分。README.md记录 DATABASE_URL、表结构说明、每个字段的含义和业务术语约定。后续用 Cursor 做页面开发时我会在对话里给 AI 加上一句“请先阅读 docs/README.md 中的数据契约再生成前端字段”这样 AI 就不会臆造出表里不存在的字段。这一步很重要因为很多 AI 生成的页面之所以跑不通就是因为前端用的字段名和后端表字段对不上。还有一个小技巧DBeaver 可以把表结构以 Markdown 或 SQL 形式导出我通常会把导出的内容粘贴到 Cursor 的对话里请它根据最新的表结构生成接口文档。这样整个开发链条里数据库始终是唯一可信的数据源。7. 这一轮数据库设计我踩过的坑与收尾记录到这一步模拟项目X的数据库已经从需求变成了运行在 Sealos 上的真实实例表结构也通过了 DBeaver 的可视化校验。但整个过程并不是一帆风顺有几个坑我认为值得记录下来它们很典型几乎每个做零代码项目的人都会遇到。7.1 坑一先让 AI 写 SQL没给需求结构我第一次尝试时直接对 DeepSeek 说“帮我写二手平台的建表语句”结果确实很快但它生成了二十多张表其中一半是我根本不需要的比如“用户积分表”“商品浏览记录表”字段设计也很随意。后来我把需求拆成实体关系描述再让 AI 生成质量立刻提升了一个档次。这个经历给我的体会是AI 的 SQL 质量完全取决于你给它的需求结构质量。7.2 坑二金额用 FLOAT时间用字符串这是最贵的两个坑。最早的表结构草稿里price 字段被 AI 写成了 FLOAT时间字段写成了 VARCHAR。当时看不出问题直到我把价格数据插入后做 SUM 统计发现结果和手算差了几分钱才意识到是浮点精度问题。时间字段用字符串更是灾难你没法按时间范围正确排序。这个坑用一句话总结就是字段类型选错代码再对也没用。7.3 坑三外键全部物理化删数据时被卡死第一版设计里我把所有逻辑关系都建了物理外键看起来很正规但实际运行时特别难受。比如管理员想删除一个违规分类数据库会因为有商品关联而拒绝删除业务上只能做标记下架根本不需要物理外键来阻碍。后来我把物理外键全部去掉只保留外键字段和索引逻辑约束交给应用层整个操作立刻顺畅了。7.4 坑四Sealos 公网连接不上用 DBeaver 连接 Sealos 上的数据库时第一次连接一直超时。排查了一圈才发现我填的是内网地址。换成公网地址后还有其他问题比如没有在安全策略里加白名单。这里分享一个排查命令在终端里执行telnet pg-abc1234.api.sealos.io 5432能连通说明网络层没问题连不通就先检查地址类型、实例是不是 Running、白名单是否包含当前 IP。别一上来就怀疑 DBeaver 配置先把链路一层层拆开。7.5 坑五DBeaver 驱动下载失败DBeaver 第一次连接 PostgreSQL 时驱动下载经常因为网络原因卡住。这时不要反复点测试去驱动设置里换个镜像源或者手动下载 jar 包放进 DBeaver 的驱动目录重启应用就能解决。这个问题不难处理但卡住时很劝退新手。7.6 这轮下来的个人体会数据库设计是整个零代码项目里最不“零代码”的环节但它也是唯一一个用最少时间投入换最长期稳定收益的环节。AI 可以把 SQL 写得很快甚至写得比我手写还规范但它不会替我做业务判断这个字段要不要默认值、那个关系要不要唯一约束、金额用元还是分。这些判断最终还是回到设计师身上。我把这些经验整理成了模拟项目X的 database-design-checklist以后每做一个新模块先从这张检查表过一遍。下一篇系列文章我们会进入真正的开发阶段到时候 Devbox 和 Cursor 就开始大显身手了。数据库这个地基已经打牢后面无论是生成页面还是部署服务都会轻松很多。