【人工智能】实战案例：用提示词生成数据库表结构设计的方法

本文介绍了利用AI工具通过提示词生成数据库表结构设计的实用方法。首先阐述了提示词的基本要素和编写原则，包括业务场景说明、表用途定义、字段要求和表关系等核心内容。接着通过三个实战案例（电商订单系统、学生信息管理系统、医院挂号系统）详细演示了如何编写有效提示词，验证AI生成结果并进行优化调整。文章还总结了提示词优化技巧、常见问题解决方法及实际应用场景，帮助开发者快速生成规范的数据库表结构，提高开发效率

猩猩优越

672人浏览 · 2025-09-11 09:40:43

猩猩优越 · 2025-09-11 09:40:43 发布

实战案例：用提示词生成数据库表结构设计的方法

1. 前言

在日常开发工作中，数据库表结构设计是非常重要的一步。一个好的表结构设计能让后续的开发工作更顺畅，也能让系统运行更稳定。传统的表结构设计需要开发者手动梳理业务需求、确定字段、选择数据类型等，过程比较繁琐。而现在，用提示词生成数据库表结构设计成为了一种新的高效方式。本文会通过多个实战案例，详细讲解如何用提示词生成数据库表结构设计，帮助开发者节省时间和精力。

2. 提示词基础认知

2.1 什么是提示词

提示词就是我们输入给 AI 工具的文字信息，目的是让 AI 按照我们的需求给出相应的结果。在生成数据库表结构设计这个场景里，提示词需要包含业务场景、表的用途、字段要求等关键信息，这样 AI 才能准确理解我们的需求，生成符合要求的表结构。

2.2 提示词的核心要素

要让提示词能有效指导 AI 生成数据库表结构，需要包含以下几个核心要素：

业务场景说明：明确这个数据库表是用于哪个业务领域的，比如电商订单管理、学生信息管理、医院患者挂号等。

表的用途定义：说明这个表主要用来存储什么数据，比如 “订单表用来存储用户下单的基本信息，包括订单编号、下单用户、下单时间、订单金额等”。

字段相关要求：包括需要包含的必填字段、可选字段，字段的数据类型要求（比如是整数、字符串、日期等），字段的长度限制（如果是字符串类型），以及字段是否允许为空等。

表之间的关系（若有）：如果涉及多个表，需要说明表与表之间的关联关系，比如一对一、一对多、多对多等，以及关联字段是什么。

2.3 提示词的语言要求

在编写提示词时，语言要简单、直接，避免使用模糊、歧义的表达。尽量用基础、常用的汉语词汇，不要用复杂生僻的术语。比如不要说 “构建一个用于对电商平台交易流程进行数据存储的结构化数据表”，可以直接说 “设计一个电商平台的订单表，用来存储用户下单的相关数据”。这样 AI 能更快、更准确地理解需求。

3. 数据库表结构设计的基本常识

在开始用提示词生成数据库表结构之前，我们需要先了解一些数据库表结构设计的基本常识，这样才能在提示词中准确提出要求，也能判断 AI 生成的结果是否合理。

3.1 常用数据类型

不同的数据库（比如 MySQL、Oracle、SQL Server）支持的数据类型略有差异，但常用的数据类型大致相同，主要包括以下几类：

整数类型：主要用于存储没有小数部分的数字，比如用户 ID、商品数量等。常见的整数类型有 INT（在 MySQL 中，INT 类型通常占用 4 个字节，能存储的范围是 - 2147483648 到 2147483647）、SMALLINT（占用 2 个字节，存储范围 - 32768 到 32767）、BIGINT（占用 8 个字节，存储范围更大，适合存储较大的数字，比如订单编号）。

字符串类型：用于存储文本信息，比如用户名、商品名称、地址等。常见的字符串类型有 VARCHAR（可变长度字符串，需要指定最大长度，比如 VARCHAR (50) 表示最多存储 50 个字符，节省存储空间）、CHAR（固定长度字符串，比如 CHAR (10)，不管实际存储的字符长度是多少，都会占用 10 个字符的空间，适合存储长度固定的数据，比如身份证号的某些固定格式部分）、TEXT（用于存储较长的文本，比如商品详情描述，不同数据库中 TEXT 类型的存储上限不同，一般能满足大部分长文本存储需求）。

日期和时间类型：用于存储日期、时间相关的数据，比如下单时间、用户注册时间等。常见的有 DATE（只存储日期，格式为 YYYY-MM-DD，比如 2025-05-20）、TIME（只存储时间，格式为 HH:MM:SS，比如 14:30:20）、DATETIME（存储日期和时间，格式为 YYYY-MM-DD HH:MM:SS，比如 2025-05-20 14:30:20，在 MySQL 中，DATETIME 类型的存储范围是 1000-01-01 00:00:00 到 9999-12-31 23:59:59）、TIMESTAMP（也存储日期和时间，格式和 DATETIME 类似，但存储范围较小，在 MySQL 中是 1970-01-01 00:00:01 到 2038-01-19 03:14:07，而且 TIMESTAMP 类型会随着时区变化而自动调整，适合存储需要考虑时区的数据）。

小数类型：用于存储有小数部分的数字，比如商品价格、折扣率等。常见的有 DECIMAL（精确小数类型，需要指定总长度和小数位数，比如 DECIMAL (10,2) 表示总共 10 位数字，其中小数部分占 2 位，能准确存储小数，适合货币相关的数据）、FLOAT（单精度浮点数，存储范围较大，但精度相对较低，可能会有精度损失，适合对精度要求不高的场景）、DOUBLE（双精度浮点数，精度比 FLOAT 高，存储范围也更大，但同样可能存在精度损失）。

3.2 字段设计原则

唯一性原则：表中应该有一个能唯一标识每条记录的字段，这个字段通常称为主键（Primary Key）。主键可以是一个字段，也可以是多个字段组合（联合主键），但推荐使用单个字段作为主键，比如用自增的 INT 类型或 UUID 作为主键。主键字段的值不能重复，也不能为空。

必要性原则：每个字段都应该有明确的用途，不要设置多余的、用不到的字段。比如在用户表中，不需要设置 “商品类别” 这样和用户信息无关的字段。

合理性原则：字段的数据类型和长度要选择合理。比如存储用户年龄，用 TINYINT 类型就足够了（TINYINT 在 MySQL 中能存储 0-255 或 - 128 到 127 的整数），不需要用 INT 类型；存储用户手机号，手机号是 11 位数字，而且可能需要存储带前缀的情况（比如 + 86），所以用 VARCHAR (20) 类型比用 INT 类型更合理。

非空原则：尽量避免字段允许为空（NULL）。如果字段允许为空，在查询和统计数据时可能会出现问题，而且会增加数据库的存储和处理开销。对于确实可能没有值的字段，可以设置默认值，比如将 “用户备注” 字段的默认值设为空字符串（''），而不是允许为 NULL。

3.3 表关系设计

在实际的业务系统中，通常需要多个表来存储不同的数据，这些表之间存在一定的关系，常见的表关系有以下三种：

一对一关系：两个表中的记录是一一对应的。比如 “用户表” 和 “用户身份证信息表”，一个用户只有一条身份证信息，一条身份证信息也只属于一个用户。在设计这种关系时，可以在其中一个表中添加一个外键字段，关联到另一个表的主键，并且这个外键字段要设置为唯一（UNIQUE）。

一对多关系：这是最常见的表关系。比如 “商品分类表” 和 “商品表”，一个商品分类下可以有多个商品，而一个商品只属于一个商品分类。在设计时，需要在 “多” 的一方（商品表）中添加一个外键字段，关联到 “一” 的一方（商品分类表）的主键。比如在商品表中添加 “category_id” 字段，关联商品分类表的主键 “id”。

多对多关系：两个表中的记录是多对多对应的。比如 “学生表” 和 “课程表”，一个学生可以选多门课程，一门课程也可以被多个学生选。这种关系不能直接在两个表中通过外键关联，需要创建一个中间表（也叫关联表）。中间表中需要包含两个外键字段，分别关联到两个表的主键。比如创建 “学生选课表”，包含 “student_id”（关联学生表主键）和 “course_id”（关联课程表主键），这两个字段组合起来作为中间表的主键（联合主键），或者再单独设置一个自增主键。

4. 实战案例准备：AI 工具选择

目前市面上有很多支持生成文本内容的 AI 工具，比如 ChatGPT、豆包、文心一言等，这些工具都可以用来生成数据库表结构设计。在选择 AI 工具时，可以考虑以下几个因素：

易用性：选择操作简单、界面友好的工具，这样即使是不熟悉 AI 工具的开发者也能快速上手。

准确性：不同的 AI 工具对提示词的理解能力和生成结果的准确性不同，建议先进行测试，选择能准确理解数据库表结构设计需求、生成结果符合要求的工具。

免费额度：很多 AI 工具提供免费额度，对于个人开发者或小团队来说，免费额度可能已经足够使用，可以优先选择有免费额度的工具，降低成本。

支持的数据库类型：有些 AI 工具能根据提示词生成针对特定数据库（如 MySQL、Oracle）的表结构语句，如果你有明确的数据库类型需求，需要选择支持该数据库类型的 AI 工具。

本文将以豆包为例进行实战演示，因为豆包操作简单、对中文提示词的理解能力较强，而且提供了一定的免费额度，适合大多数开发者使用。

5. 实战案例一：电商订单表结构设计

5.1 需求分析

本次案例需要设计一个电商平台的订单表，主要用于存储用户下单的相关信息，具体需求如下：

存储订单的基本信息，包括订单编号、下单用户、下单时间、订单总金额、支付状态、支付时间、收货地址、联系电话、订单备注。

订单编号需要唯一，不能重复。

下单用户关联用户表的主键（用户 ID）。

支付状态包括 “未支付”“已支付”“已取消”“退款中”“已退款” 这几种情况。

下单时间和支付时间需要记录具体的日期和时间。

订单总金额需要精确到小数点后两位。

收货地址和联系电话是必填项，不能为空。

订单备注是可选项，可以为空。

5.2 编写提示词

根据上述需求，编写的提示词如下：

“我需要设计一个电商平台的订单表，用来存储用户下单的相关数据。具体要求如下：

包含的字段有：订单编号、下单用户 ID（关联用户表的主键，用户表主键是 INT 类型）、下单时间、订单总金额、支付状态、支付时间、收货地址、联系电话、订单备注。

订单编号需要唯一，不能重复。

支付状态的可选值为 “未支付”“已支付”“已取消”“退款中”“已退款”。

下单时间和支付时间需要记录日期和时间，格式为 YYYY-MM-DD HH:MM:SS。

订单总金额要精确到小数点后两位，用于存储货币数据。

收货地址和联系电话是必填项，不能为空；订单备注是可选项，可以为空。

请生成针对 MySQL 数据库的表结构创建语句（CREATE TABLE 语句），并对每个字段进行说明，包括字段名、数据类型、长度（如果需要）、是否允许为空、默认值（如果有）、约束（如主键、唯一、外键等）。”

5.3 输入提示词到 AI 工具并获取结果

打开豆包 AI 工具，将上述提示词输入到输入框中，然后点击 “发送” 按钮。等待几秒后，AI 会生成相应的订单表结构设计结果，如下：

-- 电商平台订单表（order_info）

CREATE TABLE order_info (

-- 订单编号，作为主键，唯一标识一条订单记录

order_id VARCHAR(50) NOT NULL COMMENT '订单编号',

-- 下单用户ID，关联用户表（user_info）的主键（id），表示该订单属于哪个用户

user_id INT NOT NULL COMMENT '下单用户ID，关联user_info表的id字段',

-- 下单时间，记录用户下单的具体日期和时间，默认值为当前系统时间

order_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '下单时间',

-- 订单总金额，精确到小数点后两位，用于存储订单的总费用

total_amount DECIMAL(10,2) NOT NULL COMMENT '订单总金额，精确到小数点后两位',

-- 支付状态，枚举类型，只能取指定的几个值，默认值为“未支付”

pay_status ENUM('未支付','已支付','已取消','退款中','已退款') NOT NULL DEFAULT '未支付' COMMENT '支付状态：未支付、已支付、已取消、退款中、已退款',

-- 支付时间，记录用户支付订单的时间，未支付时为NULL

pay_time DATETIME NULL COMMENT '支付时间，未支付时为空',

-- 收货地址，用户的收货地址，不能为空

receive_address VARCHAR(255) NOT NULL COMMENT '收货地址，不能为空',

-- 联系电话，用户的联系电话，不能为空，设置唯一约束，避免重复（可选，根据实际业务决定是否需要唯一）

contact_phone VARCHAR(20) NOT NULL COMMENT '联系电话，不能为空',

-- 订单备注，用户对订单的备注信息，可选填，允许为空

order_remark VARCHAR(500) NULL DEFAULT '' COMMENT '订单备注，可选填',

-- 设置主键约束，主键为订单编号

PRIMARY KEY (order_id),

-- 设置外键约束，user_id关联用户表的id字段

FOREIGN KEY (user_id) REFERENCES user_info(id),

-- 可选：设置联系电话的唯一约束，如果业务要求一个手机号只能关联一个订单（通常不建议，因为一个手机号可能对应多个订单），可以添加该约束

-- UNIQUE KEY uk_contact_phone (contact_phone)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='电商平台订单表，存储用户下单的相关信息';

5.4 结果验证与调整

5.4.1 结果验证

对照之前的需求，对 AI 生成的订单表结构进行验证：

字段完整性：生成的表包含了订单编号、下单用户 ID、下单时间、订单总金额、支付状态、支付时间、收货地址、联系电话、订单备注所有需要的字段，没有遗漏。

字段属性正确性：

- 订单编号：用 VARCHAR (50) 类型，设置为非空且为主键，满足唯一性要求。

- 下单用户 ID：用 INT 类型，设置为非空，并且添加了外键关联用户表的 id 字段，符合需求。

- 下单时间：用 DATETIME 类型，设置为非空，默认值为当前系统时间，符合记录下单时间的需求。

- 订单总金额：用 DECIMAL (10,2) 类型，非空，精确到小数点后两位，适合存储货币数据，符合要求。

- 支付状态：用 ENUM 类型，枚举值包含了需求中指定的 “未支付”“已支付”“已取消”“退款中”“已退款”，默认值为 “未支付”，符合需求。

- 支付时间：用 DATETIME 类型，允许为空，符合未支付时无支付时间的情况。

- 收货地址：用 VARCHAR (255) 类型，非空，满足存储地址的需求。

- 联系电话：用 VARCHAR (20) 类型，非空，能存储包含前缀的手机号，符合需求。

- 订单备注：用 VARCHAR (500) 类型，允许为空，默认值为空字符串，符合可选填的需求。

约束正确性：添加了主键约束（订单编号）、外键约束（下单用户 ID 关联用户表），约束设置合理。

5.4.2 结果调整

经过验证，AI 生成的订单表结构基本符合需求，但有一个地方可以根据实际业务进行调整：联系电话的唯一约束。AI 在生成结果中备注了 “可选：设置联系电话的唯一约束”，但在实际的电商业务中，一个用户可能会用同一个手机号下多个订单，所以不应该给联系电话设置唯一约束，因此需要删除 “UNIQUE KEY uk_contact_phone (contact_phone)” 这行代码（如果 AI 生成了的话）。调整后的 CREATE TABLE 语句如下：

-- 电商平台订单表（order_info）

CREATE TABLE order_info (

-- 订单编号，作为主键，唯一标识一条订单记录

order_id VARCHAR(50) NOT NULL COMMENT '订单编号',

-- 下单用户ID，关联用户表（user_info）的主键（id），表示该订单属于哪个用户

user_id INT NOT NULL COMMENT '下单用户ID，关联user_info表的id字段',

-- 下单时间，记录用户下单的具体日期和时间，默认值为当前系统时间

order_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '下单时间',

-- 订单总金额，精确到小数点后两位，用于存储订单的总费用

total_amount DECIMAL (10,2) NOT NULL COMMENT ' 订单总金额，精确到小数点后两位 ',

-- 支付状态，枚举类型，只能取指定的几个值，默认值为 “未支付”

pay_status ENUM (' 未支付 ',' 已支付 ',' 已取消 ',' 退款中 ',' 已退款 ') NOT NULL DEFAULT ' 未支付 ' COMMENT ' 支付状态：未支付、已支付、已取消、退款中、已退款 ',

-- 支付时间，记录用户支付订单的时间，未支付时为 NULL

pay_time DATETIME NULL COMMENT ' 支付时间，未支付时为空 ',

-- 收货地址，用户的收货地址，不能为空

receive_address VARCHAR (255) NOT NULL COMMENT ' 收货地址，不能为空 ',

-- 联系电话，用户的联系电话，不能为空

contact_phone VARCHAR (20) NOT NULL COMMENT ' 联系电话，不能为空 ',

-- 订单备注，用户对订单的备注信息，可选填，允许为空

order_remark VARCHAR (500) NULL DEFAULT '' COMMENT ' 订单备注，可选填 ',

-- 设置主键约束，主键为订单编号

PRIMARY KEY (order_id),

-- 设置外键约束，user_id 关联用户表的 id 字段

FOREIGN KEY (user_id) REFERENCES user_info (id)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT=' 电商平台订单表，存储用户下单的相关信息 ';

## 6. 实战案例二：学生信息管理系统表结构设计

### 6.1 需求分析

本次案例需要设计学生信息管理系统的3张核心表：学生表、班级表、课程表，具体需求如下：

1. **班级表（class_info）**

- 存储班级的基本信息，包括班级编号、班级名称、所属年级、班主任姓名、班主任联系电话。

- 班级编号需唯一，不能为空。

- 所属年级用数字表示（如1表示一年级，6表示六年级）。

- 班主任姓名和联系电话为必填项。

2. **学生表（student_info）**

- 存储学生的基本信息，包括学生学号、学生姓名、性别、出生日期、所属班级、联系家长电话、学生状态（在读/休学/毕业）。

- 学生学号需唯一，不能为空。

- 所属班级关联班级表的班级编号。

- 性别仅支持“男”“女”两个选项。

- 学生状态默认值为“在读”。

3. **课程表（course_info）**

- 存储课程的基本信息，包括课程编号、课程名称、课程类型（语文/数学/英语/其他）、学分、授课教师姓名。

- 课程编号需唯一，不能为空。

- 学分用整数表示（如2分、3分）。

- 课程类型默认值为“其他”。

### 6.2 编写提示词

根据上述需求，编写的提示词如下：

“我需要设计学生信息管理系统的3张表：班级表（class_info）、学生表（student_info）、课程表（course_info），用于存储班级、学生、课程的相关数据。具体要求如下：

#### 班级表（class_info）

1. 包含字段：班级编号（class_id）、班级名称（class_name）、所属年级（grade）、班主任姓名（head_teacher）、班主任联系电话（teacher_phone）。

2. 班级编号需唯一，不能为空，作为主键。

3. 所属年级用整数类型（如1表示一年级），不能为空。

4. 班主任姓名和联系电话为必填项，不能为空；联系电话用字符串类型，可存储带前缀的号码（如+86）。

5. 生成MySQL的CREATE TABLE语句，并对每个字段说明数据类型、是否为空、约束等。

#### 学生表（student_info）

1. 包含字段：学生学号（student_id）、学生姓名（student_name）、性别（gender）、出生日期（birth_date）、所属班级（class_id）、家长电话（parent_phone）、学生状态（student_status）。

2. 学生学号需唯一，不能为空，作为主键。

3. 性别仅支持“男”“女”，用枚举类型，不能为空。

4. 出生日期用日期类型（仅存储年月日），不能为空。

5. 所属班级关联班级表的班级编号（class_id），添加外键约束。

6. 家长电话为必填项，学生状态默认值为“在读”，枚举值包括“在读”“休学”“毕业”。

7. 生成MySQL的CREATE TABLE语句，并对每个字段说明。

#### 课程表（course_info）

1. 包含字段：课程编号（course_id）、课程名称（course_name）、课程类型（course_type）、学分（credit）、授课教师（teacher_name）。

2. 课程编号需唯一，不能为空，作为主键。

3. 课程类型枚举值为“语文”“数学”“英语”“其他”，默认值为“其他”，不能为空。

4. 学分为整数类型（1-5分），不能为空。

5. 课程名称和授课教师为必填项，不能为空。

6. 生成MySQL的CREATE TABLE语句，并对每个字段说明。”

### 6.3 输入提示词到AI工具并获取结果

将上述提示词输入豆包，点击“发送”后，AI生成的结果如下：

#### 6.3.1 班级表（class_info）

```sql

-- 学生信息管理系统-班级表

CREATE TABLE class_info (

-- 班级编号，主键，唯一标识班级

class_id INT NOT NULL AUTO_INCREMENT COMMENT '班级编号，自增主键',

-- 班级名称（如一年级1班、三年级2班）

class_name VARCHAR(50) NOT NULL COMMENT '班级名称，不能为空',

-- 所属年级（1-9，分别表示1-9年级）

grade INT NOT NULL COMMENT '所属年级，整数类型（1-9），不能为空',

-- 班主任姓名

head_teacher VARCHAR(20) NOT NULL COMMENT '班主任姓名，不能为空',

-- 班主任联系电话

teacher_phone VARCHAR(20) NOT NULL COMMENT '班主任联系电话，可存储带前缀的号码，不能为空',

-- 主键约束

PRIMARY KEY (class_id),

-- 班级名称+所属年级唯一（避免同年级出现同名班级）

UNIQUE KEY uk_class_grade (class_name, grade)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息管理系统的班级表，存储班级基本信息';

6.3.2 学生表（student_info）

-- 学生信息管理系统-学生表

CREATE TABLE student_info (

-- 学生学号，主键，唯一标识学生（如2025001表示2025级001号学生）

student_id VARCHAR(20) NOT NULL COMMENT '学生学号，唯一标识，不能为空',

-- 学生姓名

student_name VARCHAR(20) NOT NULL COMMENT '学生姓名，不能为空',

-- 学生性别，仅支持男/女

gender ENUM('男','女') NOT NULL COMMENT '学生性别，仅支持“男”或“女”，不能为空',

-- 出生日期（仅年月日）

birth_date DATE NOT NULL COMMENT '出生日期，格式YYYY-MM-DD，不能为空',

-- 所属班级，关联班级表的class_id

class_id INT NOT NULL COMMENT '所属班级编号，关联class_info表的class_id字段',

-- 家长联系电话

parent_phone VARCHAR(20) NOT NULL COMMENT '家长联系电话，不能为空',

-- 学生状态，默认在读

student_status ENUM('在读','休学','毕业') NOT NULL DEFAULT '在读' COMMENT '学生状态：在读、休学、毕业，默认值为“在读”',

-- 主键约束

PRIMARY KEY (student_id),

-- 外键约束，关联班级表

FOREIGN KEY (class_id) REFERENCES class_info(class_id)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息管理系统的学生表，存储学生基本信息';

6.3.3 课程表（course_info）

-- 学生信息管理系统-课程表

CREATE TABLE course_info (

-- 课程编号，主键，唯一标识课程

course_id INT NOT NULL AUTO_INCREMENT COMMENT '课程编号，自增主键',

-- 课程名称（如小学语文、初中数学）

course_name VARCHAR(50) NOT NULL COMMENT '课程名称，不能为空',

-- 课程类型，默认“其他”

course_type ENUM('语文','数学','英语','其他') NOT NULL DEFAULT '其他' COMMENT '课程类型：语文、数学、英语、其他，默认值为“其他”',

-- 学分（1-5分）

credit INT NOT NULL COMMENT '课程学分，整数类型（1-5），不能为空',

-- 授课教师姓名

teacher_name VARCHAR(20) NOT NULL COMMENT '授课教师姓名，不能为空',

-- 主键约束

PRIMARY KEY (course_id),

-- 课程名称唯一（避免重复创建同名课程）

UNIQUE KEY uk_course_name (course_name)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息管理系统的课程表，存储课程基本信息';

6.4 结果验证与调整

6.4.1 结果验证

字段完整性：3 张表均包含了需求中要求的所有字段，无遗漏（如班级表包含班级编号、班级名称等 5 个字段，学生表包含学号、姓名等 7 个字段）。

字段属性正确性：

- 班级表的 “所属年级” 用 INT 类型，符合数字表示的需求；“班级名称 + 所属年级” 的唯一约束，避免同年级同名班级，设计合理。

- 学生表的 “性别” 用 ENUM 类型（仅男 / 女），“出生日期” 用 DATE 类型，“学生状态” 默认值为 “在读”，均符合需求。

- 课程表的 “课程类型” 默认值为 “其他”，“学分” 用 INT 类型（1-5），“课程名称” 唯一约束，符合需求。

表关系正确性：学生表的 “class_id” 关联班级表的主键，添加了外键约束，符合 “学生 - 班级” 的一对多关系（一个班级包含多个学生）。

6.4.2 结果调整

仅需对课程表做一处小调整：需求中 “学分” 要求为 1-5 分，但 AI 生成的语句未限制范围，需添加 CHECK 约束确保学分在合理区间。调整后的课程表 CREATE TABLE 语句如下：

-- 学生信息管理系统-课程表（调整后）

CREATE TABLE course_info (

course_id INT NOT NULL AUTO_INCREMENT COMMENT '课程编号，自增主键',

course_name VARCHAR(50) NOT NULL COMMENT '课程名称，不能为空',

course_type ENUM('语文','数学','英语','其他') NOT NULL DEFAULT '其他' COMMENT '课程类型：语文、数学、英语、其他，默认值为“其他”',

credit INT NOT NULL COMMENT '课程学分，整数类型（1-5），不能为空',

teacher_name VARCHAR(20) NOT NULL COMMENT '授课教师姓名，不能为空',

PRIMARY KEY (course_id),

UNIQUE KEY uk_course_name (course_name),

-- 新增CHECK约束，限制学分在1-5之间

CHECK (credit BETWEEN 1 AND 5)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息管理系统的课程表，存储课程基本信息';

7. 实战案例三：医院挂号系统表结构设计

7.1 需求分析

本次案例需要设计医院挂号系统的 4 张核心表：科室表、医生表、患者表、挂号表，具体需求如下：

科室表（dept_info）

- 存储科室信息，包括科室编号、科室名称、科室简介、科室位置。

- 科室编号唯一，不能为空。

- 科室名称唯一，不能为空（避免重复科室）。

医生表（doctor_info）

- 存储医生信息，包括医生编号、医生姓名、所属科室、职称（主治医师 / 副主任医师 / 主任医师）、擅长领域、出诊时间（如周一上午、周三下午）、联系电话。

- 医生编号唯一，不能为空。

- 所属科室关联科室表的科室编号。

- 职称为必填项，联系电话允许为空（部分医生可能不对外公开电话）。

患者表（patient_info）

- 存储患者信息，包括患者编号、患者姓名、性别、出生日期、身份证号、联系电话、家庭地址。

- 患者编号唯一，不能为空。

- 身份证号唯一（避免同一患者重复建档），不能为空。

- 家庭地址允许为空。

挂号表（registration_info）

- 存储挂号信息，包括挂号编号、患者编号、医生编号、挂号日期、就诊时间、挂号类型（普通号 / 专家号）、挂号费用、挂号状态（已挂号 / 已取消 / 已就诊）。

- 挂号编号唯一，不能为空。

- 患者编号关联患者表，医生编号关联医生表。

- 挂号费用精确到小数点后两位，默认值为 0.00。

- 挂号状态默认值为 “已挂号”。

7.2 编写提示词

根据上述需求，编写的提示词如下：

“我需要设计医院挂号系统的 4 张表：科室表（dept_info）、医生表（doctor_info）、患者表（patient_info）、挂号表（registration_info），用于存储医院挂号相关数据。具体要求如下：

科室表（dept_info）

包含字段：科室编号（dept_id）、科室名称（dept_name）、科室简介（dept_intro）、科室位置（dept_location）。

科室编号唯一，不能为空，作为主键；科室名称唯一，不能为空。

科室简介和科室位置允许为空。

生成 MySQL 的 CREATE TABLE 语句，包含字段说明、数据类型、约束。

医生表（doctor_info）

包含字段：医生编号（doctor_id）、医生姓名（doctor_name）、所属科室（dept_id）、职称（title）、擅长领域（specialty）、出诊时间（visit_time）、联系电话（doctor_phone）。

医生编号唯一，不能为空，作为主键；所属科室关联科室表的 dept_id，添加外键约束。

职称枚举值：“主治医师”“副主任医师”“主任医师”，不能为空；医生姓名不能为空。

联系电话允许为空，其他字段（擅长领域、出诊时间）不能为空。

生成 MySQL 的 CREATE TABLE 语句，包含字段说明、数据类型、约束。

患者表（patient_info）

包含字段：患者编号（patient_id）、患者姓名（patient_name）、性别（gender）、出生日期（birth_date）、身份证号（id_card）、联系电话（patient_phone）、家庭地址（home_address）。

患者编号唯一，不能为空，作为主键；身份证号唯一，不能为空。

性别枚举值：“男”“女”“其他”，不能为空；患者姓名、联系电话不能为空。

家庭地址允许为空；出生日期用 DATE 类型（YYYY-MM-DD）。

生成 MySQL 的 CREATE TABLE 语句，包含字段说明、数据类型、约束。

挂号表（registration_info）

包含字段：挂号编号（reg_id）、患者编号（patient_id）、医生编号（doctor_id）、挂号日期（reg_date）、就诊时间（visit_date）、挂号类型（reg_type）、挂号费用（reg_fee）、挂号状态（reg_status）。

挂号编号唯一，不能为空，作为主键；患者编号关联患者表的 patient_id，医生编号关联医生表的 doctor_id，均添加外键约束。

挂号日期和就诊时间用 DATETIME 类型（YYYY-MM-DD HH:MM:SS），不能为空。

挂号类型枚举值：“普通号”“专家号”，不能为空；挂号费用用 DECIMAL (10,2)，默认值 0.00。

挂号状态枚举值：“已挂号”“已取消”“已就诊”，默认值 “已挂号”。

生成 MySQL 的 CREATE TABLE 语句，包含字段说明、数据类型、约束。”

7.3 输入提示词到 AI 工具并获取结果

将上述提示词输入豆包，AI 生成的结果如下：

7.3.1 科室表（dept_info）

-- 医院挂号系统-科室表

CREATE TABLE dept_info (

dept_id INT NOT NULL AUTO_INCREMENT COMMENT '科室编号，自增主键',

dept_name VARCHAR(50) NOT NULL COMMENT '科室名称，唯一，不能为空',

dept_intro TEXT NULL COMMENT '科室简介，允许为空',

dept_location</doubaocanvas>

</doubaocanvas>

VARCHAR (100) NULL COMMENT ' 科室位置，允许为空（如门诊楼 3 层）',

-- 主键约束

PRIMARY KEY (dept_id),

-- 科室名称唯一约束，避免重复创建科室

UNIQUE KEY uk_dept_name (dept_name)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT=' 医院挂号系统的科室表，存储科室基本信息 ';

#### 7.3.2 医生表（doctor_info）

```sql

-- 医院挂号系统-医生表

CREATE TABLE doctor_info (

doctor_id INT NOT NULL AUTO_INCREMENT COMMENT '医生编号，自增主键',

doctor_name VARCHAR(20) NOT NULL COMMENT '医生姓名，不能为空',

-- 关联科室表的科室编号

dept_id INT NOT NULL COMMENT '所属科室编号，关联dept_info表的dept_id字段',

-- 医生职称，仅支持指定的三种类型

title ENUM('主治医师','副主任医师','主任医师') NOT NULL COMMENT '医生职称：主治医师、副主任医师、主任医师，不能为空',

specialty VARCHAR(100) NOT NULL COMMENT '医生擅长领域（如心血管疾病诊治、儿科常见病），不能为空',

visit_time VARCHAR(50) NOT NULL COMMENT '医生出诊时间（如周一上午、周三下午），不能为空',

doctor_phone VARCHAR(20) NULL COMMENT '医生联系电话，允许为空（不对外公开时可不填）',

-- 主键约束

PRIMARY KEY (doctor_id),

-- 外键约束，关联科室表

FOREIGN KEY (dept_id) REFERENCES dept_info(dept_id)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='医院挂号系统的医生表，存储医生基本信息';

7.3.3 患者表（patient_info）

-- 医院挂号系统-患者表

CREATE TABLE patient_info (

patient_id INT NOT NULL AUTO_INCREMENT COMMENT '患者编号，自增主键',

patient_name VARCHAR(20) NOT NULL COMMENT '患者姓名，不能为空',

-- 患者性别，支持三种类型

gender ENUM('男','女','其他') NOT NULL COMMENT '患者性别：男、女、其他，不能为空',

birth_date DATE NOT NULL COMMENT '患者出生日期，格式YYYY-MM-DD，不能为空',

id_card VARCHAR(18) NOT NULL COMMENT '患者身份证号，唯一，不能为空（18位）',

patient_phone VARCHAR(20) NOT NULL COMMENT '患者联系电话，不能为空',

home_address VARCHAR(255) NULL COMMENT '患者家庭地址，允许为空',

-- 主键约束

PRIMARY KEY (patient_id),

-- 身份证号唯一约束，避免同一患者重复建档

UNIQUE KEY uk_id_card (id_card)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='医院挂号系统的患者表，存储患者基本信息';

7.3.4 挂号表（registration_info）

-- 医院挂号系统-挂号表

CREATE TABLE registration_info (

reg_id INT NOT NULL AUTO_INCREMENT COMMENT '挂号编号，自增主键',

-- 关联患者表的患者编号

patient_id INT NOT NULL COMMENT '患者编号，关联patient_info表的patient_id字段',

-- 关联医生表的医生编号

doctor_id INT NOT NULL COMMENT '医生编号，关联doctor_info表的doctor_id字段',

reg_date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '挂号日期，默认当前系统时间，不能为空',

visit_date DATETIME NOT NULL COMMENT '就诊时间（如2025-06-10 09:30:00），不能为空',

-- 挂号类型：普通号或专家号

reg_type ENUM('普通号','专家号') NOT NULL COMMENT '挂号类型：普通号、专家号，不能为空',

-- 挂号费用，精确到小数点后两位，默认0.00

reg_fee DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '挂号费用，精确到小数点后两位，默认0.00',

-- 挂号状态，默认已挂号

reg_status ENUM('已挂号','已取消','已就诊') NOT NULL DEFAULT '已挂号' COMMENT '挂号状态：已挂号、已取消、已就诊，默认已挂号',

-- 主键约束

PRIMARY KEY (reg_id),

-- 外键约束，关联患者表

FOREIGN KEY (patient_id) REFERENCES patient_info(patient_id),

-- 外键约束，关联医生表

FOREIGN KEY (doctor_id) REFERENCES doctor_info(doctor_id)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='医院挂号系统的挂号表，存储挂号相关信息';

7.4 结果验证与调整

7.4.1 结果验证

字段完整性：4 张表均包含需求中要求的所有字段，无遗漏。例如科室表包含科室编号、名称等 4 个字段，挂号表包含挂号编号、患者编号等 8 个字段。

字段属性正确性：

- 科室表的 “科室名称” 添加了唯一约束，符合 “避免重复科室” 的需求；“科室简介” 和 “科室位置” 允许为空，符合需求。

- 医生表的 “职称” 用 ENUM 类型（仅三种指定职称），“联系电话” 允许为空，符合需求；“dept_id” 关联科室表主键，表关系正确。

- 患者表的 “身份证号” 用 VARCHAR (18) 类型（适配 18 位身份证），添加了唯一约束，符合 “避免重复建档” 的需求；“性别” 支持 “其他” 选项，符合需求。

- 挂号表的 “挂号费用” 用 DECIMAL (10,2) 类型，默认值 0.00；“挂号状态” 默认值 “已挂号”，均符合需求；“patient_id” 和 “doctor_id” 分别关联患者表、医生表主键，表关系正确。

表关系正确性：医生表关联科室表（一对多，一个科室有多个医生）、挂号表关联患者表和医生表（多对多，通过挂号表建立患者与医生的关联），表关系设计合理。

7.4.2 结果调整

需对挂号表做一处调整：需求中 “就诊时间” 应晚于 “挂号日期”，但 AI 生成的语句未限制此逻辑，需添加 CHECK 约束确保就诊时间合理。调整后的挂号表 CREATE TABLE 语句如下：

-- 医院挂号系统-挂号表（调整后）

CREATE TABLE registration_info (

reg_id INT NOT NULL AUTO_INCREMENT COMMENT '挂号编号，自增主键',

patient_id INT NOT NULL COMMENT '患者编号，关联patient_info表的patient_id字段',

doctor_id INT NOT NULL COMMENT '医生编号，关联doctor_info表的doctor_id字段',

reg_date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '挂号日期，默认当前系统时间，不能为空',

visit_date DATETIME NOT NULL COMMENT '就诊时间（如2025-06-10 09:30:00），不能为空',

reg_type ENUM('普通号','专家号') NOT NULL COMMENT '挂号类型：普通号、专家号，不能为空',

reg_fee DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '挂号费用，精确到小数点后两位，默认0.00',

reg_status ENUM('已挂号','已取消','已就诊') NOT NULL DEFAULT '已挂号' COMMENT '挂号状态：已挂号、已取消、已就诊，默认已挂号',

PRIMARY KEY (reg_id),

FOREIGN KEY (patient_id) REFERENCES patient_info(patient_id),

FOREIGN KEY (doctor_id) REFERENCES doctor_info(doctor_id),

-- 新增CHECK约束，确保就诊时间晚于挂号日期

CHECK (visit_date > reg_date)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='医院挂号系统的挂号表，存储挂号相关信息';

8. 提示词生成数据库表结构的优化技巧

8.1 明确数据库类型

在提示词中明确指定数据库类型（如 MySQL、Oracle、SQL Server），因为不同数据库支持的数据类型和语法存在差异。例如 MySQL 支持 ENUM 类型，而 Oracle 不直接支持；MySQL 的自增语法是 AUTO_INCREMENT，Oracle 是 SEQUENCE。明确数据库类型能让 AI 生成更精准的 CREATE TABLE 语句，减少后续调整工作。

示例：“请生成针对 Oracle 数据库的班级表 CREATE TABLE 语句，包含班级编号（自增）、班级名称等字段...”

8.2 细化字段要求

对字段的要求越细化，AI 生成的结果越符合预期。除了基础的字段名称和数据类型，还可以补充以下信息：

字段长度的具体数值（如 “用户姓名用 VARCHAR (20)，最多存储 20 个字符”）；

字段的默认值（如 “创建时间默认当前系统时间”）；

字段的校验规则（如 “手机号必须是 11 位数字”）；

特殊字段的格式（如 “身份证号用 VARCHAR (18)，支持 18 位数字或最后一位为 X”）。

示例：“设计用户表，包含用户手机号字段：用 VARCHAR (20) 类型，必须是 11 位数字（国内手机号），不能为空，添加唯一约束...”

8.3 清晰描述表关系

如果涉及多张表，需在提示词中清晰描述表之间的关系，包括关联字段、关系类型（一对一、一对多、多对多）。例如 “订单表和订单明细表是一对多关系，订单明细表的 order_id 字段关联订单表的 order_id 主键”，这样 AI 会准确添加外键约束，避免表关系混乱。

示例：“设计电商系统的商品表和商品分类表：商品分类表的 category_id 是主键；商品表的 category_id 字段关联商品分类表的 category_id，一个分类下有多个商品（一对多关系），请为商品表添加外键约束...”

8.4 分步骤生成复杂表结构

对于包含多张表、表关系复杂的系统（如 ERP 系统、医院 HIS 系统），不建议一次性在提示词中要求生成所有表结构。可以分步骤生成：先生成核心表（如用户表、基础配置表），验证无误后，再生成关联表（如订单表、交易表），并在提示词中引用已生成的表结构（如 “订单表的 user_id 关联已生成的用户表的 user_id 主键”）。这样能降低 AI 理解难度，减少错误。

示例：“第一步：生成电商系统的用户表（包含 user_id、username、password 等字段）；第二步：基于第一步生成的用户表，生成订单表，订单表的 user_id 关联用户表的 user_id 主键...”

9. 常见问题与解决方法

9.1 AI 生成的表结构缺少关键约束

问题描述

AI 生成的表结构可能缺少主键约束、外键约束或唯一约束。例如设计用户表时，AI 未给 user_id 添加主键约束；设计订单表时，未给 order_id 添加唯一约束。

解决方法

在提示词中明确要求添加关键约束，例如 “user_id 作为主键，添加主键约束”“order_id 必须唯一，添加唯一约束”；

生成结果后，先检查是否包含所有必要约束（主键、外键、唯一、CHECK 等），若缺少，补充提示词让 AI 补充约束，例如 “为刚才生成的用户表添加主键约束，主键为 user_id；为订单表添加唯一约束，唯一字段为 order_id”。

9.2 AI 生成的数据类型不符合需求

问题描述

AI 生成的数据类型与实际需求不符。例如存储商品价格时，AI 用了 FLOAT 类型（可能有精度损失），而实际需要 DECIMAL 类型；存储日期时，AI 用了 VARCHAR 类型（不便于日期查询和计算），而实际需要 DATE 类型。

解决方法

在提示词中明确指定数据类型，例如 “商品价格用 DECIMAL (10,2) 类型，精确到小数点后两位，避免精度损失”“创建时间用 DATETIME 类型，格式为 YYYY-MM-DD HH:MM:SS”；

若 AI 仍生成错误数据类型，补充提示词说明原因并要求修改，例如 “商品价格不能用 FLOAT 类型，因为会有精度损失，请改为 DECIMAL (10,2) 类型...”。

9.3 AI 无法理解复杂的表关系

问题描述

当表关系复杂（如多对多关系、多级关联）时，AI 可能无法正确生成关联结构。例如设计学生、课程、选课表（多对多关系）时，AI 未生成中间表 “选课表”，或未在选课表中添加关联学生表和课程表的外键。

解决方法

在提示词中拆解表关系，用简单的语言描述：“学生表和课程表是多对多关系，需要创建中间表‘选课表’；选课表包含 student_id（关联学生表的 student_id）和 course_id（关联课程表的 course_id），两个字段组合作为联合主键，或单独设置自增主键”；

分步骤生成：先生成学生表和课程表，再生成选课表，并明确引用前两张表的结构，例如 “生成选课表，student_id 关联学生表的 student_id 主键，course_id 关联课程表的 course_id 主键，添加外键约束...”。

9.4 AI 生成的字段名称不规范

问题描述

AI 生成的字段名称可能不规范，不符合开发中的命名习惯。例如字段名称用中文（如 “订单编号”），或大小写混乱（如 “OrderId”“order_id” 混用），或字段名称含义模糊（如用 “info” 代替 “remark”）。

解决方法

在提示词中明确指定字段名称的命名规则，例如 “字段名称用英文小写，多个单词用下划线连接（如 order_id、user_name），避免用中文或大小写混用”；

在提示词中直接指定字段名称，而非让 AI 自行命名，例如 “包含字段：订单编号（order_id）、下单时间（order_time）、订单金额（order_amount）...”。

10. 实际应用场景扩展

10.1 快速生成表结构初稿

在项目初期，需要快速搭建数据库框架时，可利用提示词生成表结构初稿。例如在开发一个小型博客系统时，通过提示词快速生成用户表、文章表、评论表的初稿，然后根据团队讨论结果调整细节（如补充字段、修改数据类型），相比手动编写初稿，能节省 1-2 小时的时间。

10.2 跨数据库类型迁移

当需要将数据库从 MySQL 迁移到 Oracle 时，可利用提示词生成 Oracle 版本的表结构。例如 “将已有的 MySQL 博客系统表结构（用户表、文章表、评论表）转换为 Oracle 版本，注意 Oracle 的自增语法（用 SEQUENCE）和数据类型差异（如 Oracle 无 ENUM 类型，用 VARCHAR 或 CHECK 约束替代）”，AI 会生成适配 Oracle 的 CREATE TABLE 语句，减少手动修改的工作量。

10.3 教学与学习场景

对于数据库初学者，可通过编写提示词、对比 AI 生成的表结构与标准设计的差异，学习表结构设计规范。例如初学者设计学生表后，用提示词让 AI 生成标准学生表结构，对比自己设计的字段类型、约束是否合理，从而快速掌握主键设置、外键关联、数据类型选择等知识点。

10.4 批量生成相似表结构

当系统中存在多张结构相似的表时（如不同业务线的订单表：电商订单表、生鲜订单表、服务订单表），可编写基础提示词，然后修改关键字段生成相似表结构。例如先编写电商订单表的提示词，生成后，将提示词中的 “电商” 改为 “生鲜”，补充生鲜订单特有的字段（如 “配送温度”），即可快速生成生鲜订单表，避免重复编写相似提示词。

技术共进，成长同行——讯飞AI开发者社区

更多推荐

突破瓶颈！AI应用架构师助力企业AI平台架构设计升级

在当今数字化时代，企业对人工智能（AI）的依赖程度日益加深。AI技术不仅能优化业务流程、提升效率，还能创造新的商业机会。然而，随着AI应用的不断拓展，企业在AI平台架构设计上常遭遇各种瓶颈，如性能不足、可扩展性差、数据处理困难等。AI应用架构师凭借其专业知识和经验，能够有效助力企业突破这些瓶颈，实现AI平台架构的升级。本文将深入探讨AI应用架构师在企业AI平台架构设计升级中的关键作用、涉及的核心技