做数据设计之前得先想清楚整个项目跑起来的链路是什么。黑马这个系列用的是 DeepSeek Cursor Devbox Sealos 的组合DeepSeek 负责对话推理和生成内容Cursor 负责把自然语言变成可运行的代码Devbox 提供一个云端开发环境让代码真正落地而 Sealos 承担的是应用部署和数据库托管。这一讲聚焦在最容易被忽略却最关键的环节——数据库设计我会把表结构怎么拆、字段怎么定、Sealos 上怎么部署数据库、DBeaver 怎么连库建表全部过一遍全程不手写一行代码所有建表语句都让 Cursor 配合 DeepSeek 来生成。这套流程适合谁如果你正准备跟着零代码实战的思路做项目但一说起数据库就心里没底或者你已经在用 AI 生成代码却发现生成出来的表结构东一张西一张、根本对不上业务那这篇文章正好能解决你的问题。我会用一条完整的内容管理业务线做例子把数据库从设计到部署再到可视化管理的完整流程走一遍跟着操作就能复现。1. 项目整体设计与数据库选型1.1 零代码实战的技术链路拆解零代码实战不等于不写代码而是把你的角色从“敲代码的人”变成“提需求和做决策的人”。在实际开发里我的工作流是这样先在对话中把业务需求描述清楚由 DeepSeek 负责细化和推理把模糊的想法转化成明确的数据结构和接口定义然后在 Cursor 里用自然语言下达任务让它基于前面的对话上下文生成建表脚本、接口代码甚至前端页面代码生成后放到 Devbox 这个云端环境里直接运行和调试不需要本地安装一堆运行时最后用 Sealos 一键部署应用和数据库把整个项目发布到公网可以访问。这里面最容易出问题的地方不是什么花哨的 AI 用法而是数据库。因为 AI 生成代码是“顺着你的思路走”的你思路里没有的东西它也不会主动给你补齐。如果你自己不知道要建几张表、每张表里有什么字段、两张表靠什么字段关联AI 就会给你生成一张字段混乱的大宽表或者给出一个连主键都没有的“模型”。所以数据库设计恰恰是最需要人脑参与的部分AI 只是你的打字员和翻译官。1.2 为什么选 PostgreSQL 而不是 MySQL数据库的选型是这个项目里第一个要做出的技术决策。这里选择的是 PostgreSQL而不是国内更常见的 MySQL原因有三个第一PostgreSQL 对复杂查询和 JSON 数据类型的支持更完整。零代码项目里 AI 生成的业务数据经常带有不确定的字段PostgreSQL 的 JSONB 类型允许你在一张表里存半结构化的数据不需要提前把所有字段都定义死。第二Sealos 的应用市场上对 PostgreSQL 的托管方案做得比较成熟可以一键创建高可用实例不需要你自己配置主从复制。第三PostgreSQL 的约束和索引机制比 MySQL 更严格对于 AI 生成的代码来说数据库层面的强约束可以兜住不少数据准确性问题。提示如果你有团队协作或者部署环境方面的特定要求MySQL 也不是不能用但下面讲到的 JSONB 设计部分就需要改成单独的关联表来实现了工作量会大一些。2. 数据库结构设计从业务目标到表结构2.1 核心实体拆解一个内容管理应用的数据骨架为了把数据库设计讲透我虚构一个最常见的应用场景一个带用户体系的轻量内容管理平台。用户可以注册登录、发布文章、上传附件、给自己喜欢的文章点赞管理员可以查看所有人的操作记录。整个系统浓缩下来就是四张核心表用户表、文章表、文件资源表、操作日志表。这四张表的关系并不复杂一个用户可以发布多篇文章一篇文章可以挂多个附件用户可以对文章点赞管理员的审核和用户的关键操作都落到日志表。画成图形的话就是一个标准的“一主多从”结构。真正要下功夫的是字段本身的定义方式因为 AI 生成的表结构经常在字段这一层出问题——名字起得随意、类型选错、没有默认值、没有注释这些问题会在后面联调接口的时候集中爆发。2.2 各表结构与关键字段设计用户表的字段设计要抓住一个核心思想登录凭证和业务身份分开存。凭证就是密码哈希和手机号/邮箱业务身份是昵称、头像、简介这类展示数据。AI 生成用户表时特别喜欢把头像弄成 varchar(255) 存一个 URL这个没问题但要注意头像 URL 不应该存在用户表本身的长文本字段里而应该放在文件资源表里做管理用户表只存一个资源ID。这样一张图可以同时被用户头像、文章封面、文章插图引用不会每个地方都复制一份文件地址。文章表是整个系统的重点字段设计直接决定后面接口好不好写。核心字段包括标题、摘要、正文内容、状态、发布时间、更新时间、作者ID。状态字段我建议直接用一个整数 注释的方式而不是枚举字符串因为 AI 在生成代码时对字符串枚举的匹配经常出问题比如数据库里存了字符串 “published”代码里写的是 “publish”这一类问题排查起来非常耗时。整数状态配合代码里做的枚举映射就可以避免这种情况。表格设计如下字段名类型说明idbigserial主键自增titlevarchar(200)文章标题summaryvarchar(500)摘要contenttext正文内容statussmallint0草稿、1待审核、2已发布、3已下架author_idbigint用户ID外键created_attimestamptz创建时间updated_attimestamptz更新时间文件资源表的多功能性值得展开说。它保存文件的原始文件名、存储路径、文件类型、文件大小、上传者 ID 和上传时间。这张表设计好之后用户头像、文章插图、附件下载就全部统一走一套上传逻辑。路径字段推荐存相对路径而不是完整 URL因为以后如果你换了 CDN 或者换了域名完整 URL 会让你不得不写批量更新脚本改数据存相对路径只要在访问层做拼接就行。操作日志表是 AI 生成的时候最容易漏掉的一张表。内容管理平台必须有审核和追踪的概念推送给 AI 的需求里如果没提到日志它就不会帮你建。日志表字段包含操作用户、操作类型、操作对象类型、操作对象 ID、操作详情JSONB、操作时间。操作类型用整数枚举比如 1 新增、2 修改、3 删除、4 审核通过、5 审核拒绝。操作详情用一个 JSONB 字段可以记录修改前的值和修改后的值以后做审计回查非常方便。2.3 公共字段设计与索引规划四张表里都有一组公共字段id、created_at如果涉及修改还有 updated_at。有些 AI 生成的建表脚本会漏掉这些字段或者有的表有、有的表没有这是很典型的“AI 风格不一致”问题。解决办法是把公共字段的口径放在需求描述里直接给到 AI比如说“所有表都必须包含 id类型 bigserial 主键、created_at类型 timestamptz默认值 now()涉及内容修改的表额外增加 updated_at”。这样生成的脚本风格才能统一。索引方面除了主键索引业务查询常用的字段也要建索引。文章表需要在作者 ID 和状态字段上建联合索引因为前台的文章列表几乎总是“某个作者 状态为已发布”这样的组合查询。日志表需要在操作对象类型和操作对象 ID 上建索引因为回查一条业务数据的变更履历时查询频次很高。JSONB 字段本身在 PostgreSQL 里可以建 GIN 索引但如果只是存修改前后快照而不基于内容做检索就没必要建。注意表结构设计到这一步先不要急着让 AI 一次性生成全部建表 SQL。我建议你先和 AI 对话让它给你一个“字段字典”也就是每张表字段的含义清单你过目确认之后再让它生成建表脚本。字段字典这一步能帮你提前发现设计层面的问题让 Cursor 直接生成代码问题会晚到但不会消失排查成本高得多。3. 在 Sealos 上部署 PostgreSQL 实例3.1 为什么把数据库放到 Sealos 而不是本地安装既然这个系列叫零代码实战那么从部署层面就应该尽量避免在本机装数据库。很多新手在这里栽了跟头——下载安装 PostgreSQL 客户端工具、配置环境变量、解决本地端口冲突、处理服务启动失败……一套流程下来几个小时就没了还没开始写业务逻辑呢信心先被磨掉一半。而且本地和云端的数据库版本不一致还会出现本地跑得好好的、部署到线上之后格式对不上的问题。Sealos 提供的是一个开箱即用的云原生环境可以把它理解成一台预装好各种工具的远程服务器数据库、应用部署、依赖管理都在网页上点几下就完成。你不需要知道 Kubernetes 怎么操作也不需要为了一个演示项目去研究 Docker ComposeSealos 把这些底层细节都包住了。3.2 创建 PostgreSQL 实例的完整步骤整个过程可以分成三步第一步在 Sealos 的控制台里找到应用市场搜索 PostgreSQL选择 PostgreSQL 16 或当前市场提供的最新稳定版本。我这里建议你选择带 “HA” 标识的版本HA 就是高可用底层会自动做主从同步虽然单机模式也能跑但数据库这种核心组件值得多一点保障。第二步配置实例规格。对于内容管理平台这个量级的项目CPU 和内存各分配一个核到两个核就足够了存储容量建议设置 10 GB 以上。这里有一个容易忽略的地方存储容量直接决定你的 PostgreSQL 可以保留多少天的数据如果设置得太小后面做数据迁移或者导入初始化数据的时候会发现空间不够用再扩容虽然也可以在控制台操作但中间会涉及数据重分布没必要给自己找这个麻烦。第三步设置数据库密码和访问白名单。Sealos 创建的 PostgreSQL 实例默认带有外网连接地址这很方便但同时也意味着任何知道地址的人都可以尝试连接你的数据库。密码务必设置得复杂一些建议是大小写字母加数字加符号的混合体。访问白名单如果 Sealos 支持配置就把你的开发机 IP 加进去浏览器搜索 “IP” 就能看到自己的公网出口 IP。这个步骤虽然是额外操作但对数据安全的意义很大。创建完成之后Sealos 会给你一组连接信息包括主机地址、端口、数据库名、用户名和密码。把这些信息做成一个连接字符串格式大概是 postgresql://用户名:密码主机地址:端口/数据库名。这串字符后面要用于两件事一是配置 DBeaver 连接二是作为业务后端的环境变量。3.3 初始化业务库和账号Sealos 创建的 PostgreSQL 默认数据库和用户是用作管理的直接拿它来存业务数据虽然也能跑但不专业。建议连接到实例之后先做一次初始化操作创建一个专门的业务数据库和一个业务账号业务账号只对业务数据库有操作权限。这样以后即使业务代码出现问题也不会波及 PostgreSQL 的系统库以及其他项目共享的资源。初始化操作用一段 SQL 就能完成CREATE DATABASE app_db; CREATE USER app_user WITH PASSWORD your_strong_password; GRANT ALL PRIVILEGES ON DATABASE app_db TO app_user;如果后续要用这个账号建表还需要在业务数据库里把 schema 的权限也授权给它否则会出现账号能连接数据库但执行 CREATE TABLE 时被拒绝的情况。不难但确实是我第一次用云端数据库实例时踩过的坑。4. DBeaver 连接数据库与可视化建表4.1 DBeaver 的下载安装与环境设置DBeaver 是目前做数据库可视化管理的首选工具特点是对所有主流数据库一视同仁驱动管理非常方便。我要重点推荐 DBeaver Community 版也就是社区版免费且功能足以覆盖整个项目的开发调试。安装过程中要注意一个看似奇怪但很实际的问题DBeaver 需要 JDK 环境但你的电脑上装的 JDK 版本可能和 DBeaver 内置的不兼容。默认情况下 DBeaver 会尝试使用系统安装的 JDK如果遇到启动报错或者连接数据库的时候提示驱动加载失败不要急着重装软件先去 DBeaver 的安装配置里把使用的 JDK 路径切换成它自带的版本或者手动指定一个版本合适的 JDK。热词里有人搜“dbeaver 修改 jdk 版本”说的就是这个问题。对于中文用户DBeaver 的界面默认是英文可以打开菜单里的偏好设置在用户界面选项的语言里选择中文并重启软件。这个过程不需要汉化包软件本身就自带多语言资源只是默认不开启而已。4.2 配置 PostgreSQL 连接打开 DBeaver 之后按照下面的步骤建立连接第一步点击左上角新建连接图标在数据库类型列表里选择 PostgreSQL。如果列表里没有这个选项先检查软件版本社区版默认是包含所有主流数据库驱动的。第二步填入连接信息。主机填 Sealos 给你的公网地址端口填默认的 5432数据库名填你创建的业务库名用户名和密码对应你的业务账号。这里有一个常见误区很多人拿着管理员的用户名和密码去连业务库结果也能连上但之后建表记录全部归属于管理员账号运维上的隔离性就差了很多。第三步点击测试连接。如果提示连接成功说明整条链路已经通了。如果测试失败优先检查三个地方密码是不是粘贴的时候带了空格、白名单里有没有加当前 IP、连接地址是不是漏掉了端口号。连接成功之后你可以右键连接名称查看数据库结构导航这里会展示 PostgreSQL 实例里的所有数据库、schema、表、索引和约束。接下来要做的就是执行建表脚本。DBeaver 内置了一个 SQL 编辑器用法很简单点击工具栏上的 SQL 编辑器图标把 AI 生成的建表 SQL 粘贴进去选中全部语句按执行按钮。执行完成之后在左侧结构树里右键刷新就能看到新创建的表。如果脚本里有报错DBeaver 的错误信息会定位到具体的行号复制错误信息丢回给 Cursor让 AI 自己修正通常一两轮对话就能解决。4.3 用 ER 图校验表设计的合理性表建好之后有一个强烈推荐做的操作查看 ER 图。在 DBeaver 的数据库导航里找到你的业务数据库右键选择 ER 图软件会根据外键关系自动生成实体关系图。这个图可以直观地看到四张表之间是如何关联的有没有箭头指向错误、有没有孤立的表、有没有缺少外键的情况。我见过很多 AI 生成的建表脚本表能建出来但外键完全没有表和表之间没有任何关系纯粹是几张独立的表凑在一起。这种问题在 ER 图里一眼就能看出来。如果发现外键缺失直接在 DBeaver 里对表执行外键约束的添加语句或者把 ER 图截图发给 Cursor让它重新生成带外键的建表脚本。提示ER 图不只是给数据库设计阶段用的后面写接口代码的时候也可以对照着看。哪个接口需要关联查询哪几张表看一眼 ER 图就能确定查询路径比你自己记表结构省力太多。5. 初始化数据验证与常见问题排查5.1 用种子数据验证表结构表建好之后不要着急开始写接口先往表里插入几条测试数据验证整个结构能不能支持真实业务。这一步在数据库开发里叫种子数据填充看起来不起眼其实是发现设计缺陷最快的路径。我通常会往用户表插入两三个用户往文章表插入两篇不同状态的文章再往文件资源表插入一条图片记录确保外键关系能正常连接。接着执行几条查询语句模拟真实业务场景比如查询某个作者的所有已发布文章、查询某个文章的完整信息包括作者昵称和封面图、查询某个用户最近的操作记录。这些查询如果在数据库层面执行不顺畅比如要写多条 SQL 才能拼出数据说明表结构的设计还有调整空间。种子数据验证还有一个好处给 AI 后面的代码生成提供了上下文。你在对话里告诉 Cursor“现在数据库里的测试数据情况如下……”AI 生成的代码会更贴近实际数据结构而不是只凭空想象的模型去生成接口代码。5.2 常见问题速查表整个数据库设计、部署、连接的过程中有几类问题是出现频率最高的我整理成了一张速查表方便遇到问题的时候直接对照查找。问题现象可能原因排查思路测试连接超时不通白名单未配置或输入了错误的密码检查访问白名单里是否有当前出口 IP并确认密码无隐藏字符连接成功但看不到业务库使用管理账号连接而非业务账号切换为业务账号或在连接配置里修改数据库名执行建表 SQL 报错权限不足或语法与版本不匹配确认账号是否有 schema 权限将报错信息复制给 Cursor 修正中文内容乱码客户端字符集与服务器不一致在 DBeaver 连接配置里强制设置编码为 UTF-8ER 图里表之间没有连线外键约束缺失让 AI 补充外键约束或手动添加外键字段信任校验但不要依赖校验AI 只是把你的业务需求翻译成技术实现但连不连得上、结构是否合理还是需要你自己去数据库里验证一遍。5.3 我在实操中的三点心得数据库设计这个环节是整个零代码实战项目里性价比最高的投入。前面花两小时把表结构想清楚后面 AI 生成接口代码、前端页面的速度会快很多因为数据结构稳定之后代码生成的上下文就非常明确了。我实际试下来有几个经验值得分享第一让 AI 先出文档再出代码。你可以先让 DeepSeek 帮你整理一份数据库设计文档把每个表的用途、字段含义、表间关系用自然语言描述清楚再用这份文档作为 Cursor 生成代码的参考。第二把字段字典和建表脚本分开生成。一次性要求 AI 生成全套容易出错分两步走每一步都能验证。第三每建完一张表就立刻用 DBeaver 检查一次不要四张表全部建完之后再统一看那时候出了问题就很难定位是哪张表导致的。这套组合看起来工具很多但实际跑通之后你会发现思路非常清晰DeepSeek 出设计Cursor 出代码Sealos 管部署DBeaver 管数据。数据库这块扎实了后面的接口开发就水到渠成了。最后再补充一个小技巧把连接字符串保存到你的 Devbox 环境变量里不要每次使用的时候复制来复制去减少出错概率。下一节就可以进入接口设计了数据库的活干得越漂亮后面写代码的日子就越轻松。