数据库设计Skill：让 AI 帮你在建表前把模式、索引与迁移一次想清楚
- 一个专注数据建模的技能：覆盖关系型（PostgreSQL、MySQL）、NoSQL（MongoDB、Redis、Cassandra）、时间序列（TimescaleDB、InfluxDB）、事件溯源与数据仓库五大类场景，不是泛泛聊数据库，而是直接给出可执行的 DDL 与模式设计。
- 从需求到迁移的全链路：先把实体、关系、访问模式、数据量估算理清，再输出表结构、索引、约束、分区策略，最后补齐带回滚的迁移脚本。
- 可直接落盘的工程化产物：技能允许读取、grep、glob、编辑、写入、bash 等工具，意味着它能在项目里读代码、写文件，而不是只在对话框里"讲道理"。
- 典型收益：把"拍脑袋建表—上线后发现慢查询—返工改结构"的循环，提前到设计阶段解决；对中小团队而言，相当于常驻了一位随时可问的数据建模顾问。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 中文名 | 数据库设计Skill |
| 英文名 | database-design |
| 技能ID | 13514 |
| 触发关键词 | 模式、表、列、迁移、ERD、规范化、反规范化、索引、外键、主键、约束、关系、SQL、DDL、数据模型、数据仓库、星型模式、雪花模式、时间序列、事件溯源、维度表、事实表、ETL、数据管道、OLAP、OLTP 等 |
| 可用工具 | 读取、grep、glob、编辑、写入、bash |
它解决什么问题
日常开发中，数据库设计往往是最容易被"顺手糊弄"的环节：需求会上没人画 ERD，建表时字段类型随手写，索引用"以后再加"搪塞，等数据量涨到几百万行，才发现 JOIN 没有索引、状态字段没有约束、金额用了浮点数、迁移脚本没有回滚。数据库设计Skill 的价值就在于把这些隐性债务显性化——它会先追问数据访问模式（读多还是写多、按什么条件查、怎么排序分组），再给出对应的模式设计、索引方案和反规范化取舍。
一键安装的思路与步骤
"一键安装"的本质，是把技能的说明文件放进 AI 编程助手能够读取的技能目录，让助手在后续对话中自动加载这套数据库设计方法论。具体操作路径各平台不同，以下步骤为通用思路，具体命令、目录与入口请以官方说明为准：
- 确认前提：你使用的 AI 编程助手/客户端需要支持"技能（Skill）"机制，并具备读取本地文件的能力（本技能声明需要读取、编辑、写入与 bash 等工具权限）。
- 获取技能：在技能市场、技能仓库或团队内部技能库中检索技能ID 13514 或英文名 database-design，找到对应条目。
- 一键安装：点击安装/添加按钮，或按官方文档给出的命令行方式安装。安装后技能文件通常会被放入技能目录中。
- 验证是否生效：新开一个会话，直接输入一句触发语，例如"帮我设计一个电商订单表，要求支持状态流转和按时间范围查询"，若助手开始追问实体关系、访问模式、数据量级，并输出带主键、外键、CHECK 约束与索引的 DDL，说明技能已加载成功。若回答仍是泛泛而谈，请检查技能是否被正确启用、当前会话是否重新加载。
- 授权与安全：因为该技能涉及写入与 bash 权限，建议先在测试分支或沙箱项目中试用，确认产物无误后再用于生产仓库。
2. 该技能的主要功能和特点
核心能力清单
- OLTP 事务型建模：按第三范式规范化建表，区分代理键与自然键，定义主键、外键与级联规则，选择合适的字段类型（INT 与 BIGINT、VARCHAR 与 TEXT、DECIMAL 与 FLOAT），处理 NULL 与默认值，并用 CHECK 约束兜住数据完整性。
- OLAP 分析型建模：输出星型模式（中心事实表 + 维度表）或雪花模式（高基数场景下规范化维度），设计缓慢变化维度（SCD 类型 1/2/3）、代理键、事实表的度量列与退化维度。
- 时间序列设计：以时间戳作为主键组成部分，按天/周/月分区，面向仅追加写入，配套降采样与聚合表、保留策略。
- 事件溯源建模：设计不可变的仅追加事件表，包含事件类型、聚合ID、时间戳、负载与元数据，规划投影（读模型）、快照与事件版本演进。
- 索引与性能优化：针对 WHERE、JOIN、ORDER BY、GROUP BY 设计索引，考虑覆盖索引、部分索引、物化视图、分区策略（范围/哈希/列表）以及并发控制（乐观锁与悲观锁）。
- 迁移与演进：生成包含 UP 与 DOWN 的可逆迁移脚本，处理数据回填与默认值，规划零停机的"扩展—收缩"部署，并在生产规模数据上验证。
- ETL/数据管道配合：设计批量加载友好的模式、暂存表、审计列（created_at、updated_at、loaded_at）、变更数据捕获（CDC）以及幂等的 upsert 逻辑。
和普通工具比强在哪
普通建表工具（如数据库客户端、ORM 生成器）只负责"把你写的字段变成 DDL"，不判断这个结构是否合理；通用 AI 助手能聊数据库，但容易给出没有约束、没有索引、没有回滚的"半成品"。数据库设计Skill 的差异在于：它把规范化取舍、索引选择、迁移可逆性、幂等性这些工程约束写进了流程，输出物更接近一份可以直接提交评审的设计方案——示例中的电商模式就同时给出了唯一约束、正则 CHECK、GIN 全文索引、JSONB 地址字段与级联删除规则。
3. 如何使用该技能？
以下为典型使用流程，具体交互入口以你所用客户端的官方说明为准。
- 描述业务场景与实体。不要只丢一句"帮我建个表"，而是说明实体、属性和业务规则。示例输入：
我在做一个电商系统，需要用户、商品、分类、订单、订单明细五张表。订单状态有 pending/paid/shipped/delivered/cancelled，商品价格不能为负，订单要支持按用户和按时间范围查询，预计三年内订单量 5000 万。
- 补充访问模式与数据量。明确哪张表读多写多、常用查询条件是什么、是否需要分页与排序、数据保留多久。这一步直接决定索引与分区方案。
- 让技能先给设计说明，再给 DDL。可要求它先输出实体关系说明（ERD 文字版）、主外键与约束清单、索引清单，再产出建表语句，便于评审。
- 获取可执行 SQL。技能会输出带约束与索引的建表语句，例如用户表使用 UUID 主键、邮箱唯一约束与正则 CHECK，订单表对状态字段加 CHECK 白名单，订单明细表对 (order_id, product_id) 建唯一约束并配置 ON DELETE CASCADE。
- 要求生成迁移脚本。示例输入："在现有用户表上增加忠诚度等级与积分字段，并新建积分历史表，要求可回滚。"输出会包含版本号、事务包裹的 UP 脚本、约束定义、索引创建，以及单独保存的 DOWN 回滚脚本。
- 按需切换到分析场景。输入"把上面的销售数据做成数据仓库"，会得到 dim_date、dim_product（含 SCD 类型 2 列与 is_current 部分索引）、dim_customer、fact_sales 的设计，以及按年月/品类/区域预聚合的物化视图。
- 落地与复核。把 SQL 提交到版本库、在测试库执行、用真实量级数据验证执行计划；如涉及写入本地文件，可让技能直接把脚本写入项目的 migrations 目录（需写入权限）。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 数据库设计Skill（database-design） | 面向多种数据库范式的 AI 数据建模助手 | 规范化/反规范化取舍、索引与分区设计、可逆迁移、星型/雪花模式、时序与事件溯源、ETL 暂存与幂等 upsert | 需支持技能机制的 AI 客户端，安装流程以官方说明为准；用自然语言描述需求即可 | 新项目建表、遗留库重构、数仓建模、迁移脚本编写 | 优势：覆盖 OLTP/OLAP/NoSQL/时序/事件溯源，输出可执行 DDL 且自带回滚；不足：依赖使用者把业务规则讲清楚，最终仍需人工评审与压测 |
| 人工 DBA / 资深后端设计 | 传统专家经验路径 | 全面但依赖个人水平 | 人力成本高、排期长 | 核心交易系统、强合规场景 | 优势：经验与上下文最完整；不足：供给稀缺、沟通成本高、文档沉淀不稳定 |
| 通用 AI 对话助手 | 通用问答 | 能聊数据库概念、写简单 SQL | 门槛极低 | 学习概念、临时写几条查询 | 优势：随手可用；不足：容易漏掉约束、索引、回滚与幂等，方案完整性不稳定 |
| 数据库建模工具 / ERD 软件 | 图形化建模 | 可视化实体关系图、正向/反向生成 DDL | 需学习工具操作，部分能力需付费（以官方说明为准） | 团队评审、文档交付 | 优势：图直观、适合汇报；不足：不主动给性能与规范化建议，索引与迁移策略仍需人判断 |
| ORM 自动迁移工具 | 代码优先的框架能力 | 由模型类自动生成表结构与版本迁移 | 与具体框架强绑定 | 单体应用快速迭代 | 优势：开发体验顺滑；不足：复杂索引、分区、物化视图、跨库分析建模支持有限 |
5. 该技能的典型应用场景与实际体验情况
场景一：创业团队从零搭建电商后台
角色是唯一的后端工程师，痛点是"既要快上线，又怕结构留坑"。使用方式是先描述五张核心表与订单状态机，让技能给出规范化到第三范式的结构，并补上提交给评审用的约束清单。实际体验：上手几乎零门槛，只要把业务规则说清楚；输出质量明显高于直接问通用助手，尤其是邮箱正则 CHECK、状态白名单、订单明细唯一约束这类"容易被忘"的细节会被主动补上。注意事项：金额字段务必确认使用 DECIMAL 而非浮点，需求描述里要写明"价格不能为负"这类规则。
场景二：数据分析团队搭建销售数据仓库
角色是数据分析工程师，痛点是业务库直接跑报表越来越慢。使用方式是要求按星型模式设计维度与事实表，并生成月度销售的物化视图。实际体验：技能会主动引入代理键、SCD 类型 2 的 effective_date/expiration_date/is_current 三件套，并给出 WHERE is_current = TRUE 的部分索引，这部分经验对没做过数仓的工程师价值很高。注意事项：SCD 类型选择要结合业务（是否需要追溯历史归属），否则维度表会不必要地膨胀。
场景三：IoT 平台的指标存储
角色是平台研发，痛点是设备上报数据写入量大、查询按设备和时间。使用方式是描述写入频率、保留 90 天、需要按小时聚合。实际体验：技能给出以 (time, device_id, metric_name) 为主键的超表设计、按天分块、压缩与保留策略、按小时连续聚合的物化视图，思路完整。注意事项：分区粒度与压缩策略需要结合真实写入速率调整，建议先小规模验证。
场景四：需要审计与时间回溯的账务系统
角色是金融类业务的后端，痛点是"任何余额都必须能解释清楚是怎么来的"。使用方式是要求事件溯源设计。实际体验：能给出仅追加事件表、聚合内唯一序号实现乐观并发、快照表降低重放成本，以及用 SQL 函数从事件重建余额的写法。注意事项：事件负载的版本演进要提前规划，投影更新建议放在应用层而非数据库触发器，以便测试。
6. 该技能能为用户带来的价值
- 把返工成本前移：索引缺失、类型选错、约束缺失这三类问题一旦上线，修复往往伴随数据迁移与停服窗口。技能在设计阶段就把这些点补齐，减少后期"改结构"的概率。
- 降低专业门槛：星型模式、SCD、事件溯源、幂等 upsert、零停机扩展收缩，这些原本需要多年经验积累的套路，被整理成可复用的检查项，中级工程师也能产出接近资深水准的设计。
- 缩短设计周期：一份包含表结构、约束、索引、迁移脚本的设计稿，从"想两天"压缩到"一次对话 + 一轮评审"，评审时也有具体的 DDL 可讨论，而不是抽象的描述。
- 沉淀团队资产：输出的 ERD 说明、数据字典、版本化迁移脚本可以直接进仓库，成为长期可维护的文档；审计列与版本字段的统一约定，也让后续排查有据可依。
- 长期价值：数据库模式是全系统最难改的部分。设计阶段多花的一小时，通常能在半年后省下数十小时的排查与迁移工作。
7. 常见问题 FAQ
Q1：怎么安装这个技能？需要付费吗？
A：安装方式取决于你使用的 AI 客户端，通常在技能市场或技能仓库中检索技能ID 13514 或英文名 database-design 后一键添加，具体命令、目录与入口请以官方说明为准。是否收费同样以官方说明为准，本技能本身未在详情中声明定价信息。安装后建议用一句"帮我设计一个带状态约束的订单表"来验证是否生效。
Q2：它会不会直接改我的数据库？
A：不会。技能声明的工具是读取、grep、glob、编辑、写入、bash，能力边界是"读取项目文件、写出 SQL 与脚本文件、执行命令"，数据库结构的实际变更仍需要你自己在目标环境中执行 SQL。建议先在测试库执行，确认无误再上生产。
Q3：我不懂数据库理论，能用吗？
A：能用，但效果取决于你提供的业务信息。你不需要知道第三范式是什么，但需要说清楚：有哪些实体、实体之间是一对多还是多对多、常用的查询条件是什么、数据量大概多大、数据要保留多久。这些信息给得越具体，输出的索引与分区方案就越贴合实际。
Q4：它和通用 AI 助手写 SQL 有什么区别？
A：通用助手通常只回答"这条 SQL 怎么写"，本技能是按流程走完"理解数据需求 → 设计模式 → 优化性能 → 计划迁移 → 考虑 ETL 影响"五步，输出物包含约束、索引、回滚脚本与幂等方案。差异在完整性：前者给你一段能跑的语句，后者给你一份能评审、能演进的方案。
Q5：适合谁用？和建模工具怎么选？
A：最适合后端工程师、数据工程师、数据分析师以及需要独立完成从设计到上线的小团队。如果团队已有成熟的建模工具并主要为了画图汇报，可以继续用工具出图、用本技能补索引与迁移策略；如果是从零设计新库或重构遗留库，直接用它出方案效率更高。二者并不冲突，常配合使用。