用AI做数据库设计，最尴尬的场景是什么？就是AI一口气给了一整套看上去无懈可击的建表语句，你复制进命令行，第一条INSERT就报外键错误。最近在学校帮人看课程设计，好几个项目都是同一类题目：在AI工具的辅助下创建一个校园管理系统，主营方向是二手物品交易。这个题说难不难，但要把DDL、DML、外键关系、ER图、每张表至少10条数据一次性理清楚，还真有几个绕不过去的设计决策。这篇文章我就把整个设计过程完整拆开，从业务思考到表结构，再到可以直接跑的SQL脚本和填充数据，最后分享一些AI辅助实操时的提示词技巧和排错经验，希望对你正在做的这个课设或者练手项目有实际帮助。

1. 动手前先想清楚：二手交易系统到底要解决哪些问题

1.1 把标题里那个未完成的问句补完

项目标题最后写了一句"需要思考：二手物品交易需……"，这句话断掉了，但方向其实已经点得很明白。做这个系统，第一件事不是写建表语句，而是把"二手物品交易需要什么"这个问题补完整。我的答案是：需要四个核心问题被解决。

第一，物品信息怎么管理。二手物品和普通商品最大的区别是"非标"，同样一台自行车，用了半年和用了三年的价格、成色、描述都完全不同，所以商品表必须能承载标题、描述、价格、成色、图片、发布者这些信息。第二，交易关系怎么建立。买卖双方不一定是好友关系，买家是通过浏览商品发现卖家的，所以需要商品挂到卖家名下，同时订单要同时记录买家、卖家两个角色。第三，买卖双方怎么沟通。校园二手交易往往是当面交付，买家会问"在哪个宿舍楼""能不能便宜""东西有没有瑕疵"，所以需要留言咨询表来承载这些对话。第四，交易状态怎么流转。商品从"在售"到"已售出"，订单从"待确认"到"已完成"，状态不一致很容易出现一物多卖或者订单跑飞的情况。

这四个问题，就是整张数据库设计的地基。

1.2 从业务映射到表：六张核心表的由来

基于上面四个问题，我最后确定了六张表，它们不是拍脑袋定的，每一张都能在业务里找到对应支点。

• 用户表：承载买家、卖家、管理员三种角色。
• 分类表：承载物品分类，让商品可以按类浏览。
• 商品表：承载物品的完整描述、成色、价格与状态。
• 订单表：承载交易关系，记录谁买了谁的东西、多少钱、什么状态。
• 留言表：承载买家对商品的咨询与卖家回复。
• 收藏表：承载买家对商品的收藏意向，相当于轻量级的关注清单。

有同学会问，要不要再建一张购物车表？我的判断是不需要。校园二手商品大多是低频、低价值、当面交付，买家下单通常不需要像电商平台那样攒一批商品一起结算。收藏表本身已经起到了"先留着，回头再看"的作用，购物车在这里属于典型的多余设计。如果你非要加，后续演进也不难，但第一版没必要给自己增加工作量。

1.3 校园场景带来的特殊字段

这套系统和普通的电商数据库比，有几个字段是校园场景特有的，我在设计时专门做了保留。

学号字段需要唯一。校园二手交易的前提是"同校信任"，学号唯一既能保证用户身份可追溯，也能防止一个人注册多个小号刷信用。信用分字段很有必要，二手交易最怕放鸽子和货不对板，给用户一个默认100分的初始信用分，交易异常时扣分，页面展示出来，能起一定的约束作用。学院字段看着不起眼，但实际很有用，很多校园二手平台都支持按学院筛选，用户也天然倾向于和同学院的校友交易。商品成色字段不能省，成色不好描述，但可以用枚举值约束，比如"全新、几乎全新、轻微使用、明显使用痕迹"，比让用户自由填文本更规范。

这些字段都是在AI生成草稿时很容易被忽略、但真正跑业务时又绕不开的细节。

2. 表结构设计：六张表的核心字段与外键关系怎么定

2.1 用户表：身份、角色和信用从哪里来

用户表我命名为user，包含用户ID、学号、登录账号、昵称、密码哈希、手机号、学院、信用分、角色、注册时间。密码字段一定要强调存哈希，不要存明文，这是底线问题。

学号和登录账号各建一个唯一索引，防止重复。角色字段用ENUM('USER','ADMIN')处理，不需要单独建管理员表，因为管理员的功能主要是下架违规商品和管理分类，在用户表加一个角色标识足够。

信用分字段credit_score初始值给100，后续业务逻辑里再根据取消订单次数、被投诉情况扣分。这里有个小经验：信用分用INT就够，没必要用DECIMAL，因为你基本只会做整数加减。

2.2 分类表：为什么不能省

有些同学图省事，在商品表里直接存一个category_name字符串，看起来简单，实际后患无穷。同一个分类，有人写"数码"，有人写"数码产品"，有人写"数码影音"，后台统计数据的时候你会疯掉。

独立的分类表category只要三四个字段就够：分类ID、分类名称、排序权重、分类说明。排序权重sort_order用来控制首页分类展示顺序，这个字段在AI第一版脚本里几乎不会出现，但实际运营时很有用。

商品表通过category_id外键引用分类表，这样分类改名只需要更新分类表的一行数据，所有该分类下的商品自动统一。

2.3 商品表：价格精度和状态流转是核心

商品表product是整套系统里字段最多的表，也是最需要认真设计的一张。除了常规的标题、描述、图片、浏览量，我特别提醒三个点。

价格字段必须用DECIMAL(10,2)，禁止用FLOAT。这是数据库课设里最爱挖的坑之一：浮点数在计算时存在精度丢失，比如0.1加0.2可能变成0.30000000000000004。价格出现这种情况，订单合计金额对不上，是很严重的业务事故。DECIMAL(10,2)表示最长10位数字、小数占2位，存放几十万以内的金额都够用。

成色字段condition_level用ENUM枚举约束，保证数据规范。状态字段status同样用ENUM('在售','已售出','下架')，注意这里没有"删除"状态，因为商品被订单引用后就不能物理删除了，只能用"下架"做逻辑删除。

浏览量字段views建议做进去，虽然课程设计里不一定用到排序，但有了这个字段，后续做"热门商品"功能就不用回头改表。

2.4 订单表：快照字段和外键唯一约束双保险

订单表orders是这套设计里最体现功力的地方。除了常规的订单号、买卖双方ID、成交价、状态、下单时间，我加了两个很多人会漏掉的东西。

第一是快照字段product_title和deal_price。为什么要冗余？因为二手商品的标题和价格，卖家在卖出前可能修改。如果不做快照，历史订单里商品标题被卖家改成别的了，你根本不知道当时成交的是什么。快照字段在订单创建那一刻把商品标题和成交价拷贝一份进来，历史订单永远可追溯。

第二是product_id上加了唯一约束。这是防止"一物多卖"的关键。没有这个唯一约束，两个买家可能同时对同一件商品下单成功，业务层判断再严谨也会有漏洞。数据库直接把这条路堵死，同一个商品最多只出现在一笔订单里。

订单状态我用ENUM('待确认','已完成','已取消')。这个设计贴合校园二手当面交易的场景：买家下单后卖家确认，线下见面交付后变成已完成。很多电商的"待发货、待收货、待评价"那一套在这里并不适用。

2.5 留言表和收藏表：买卖双方的连接器

留言表message记录的是"某个用户对某个商品发起的咨询"，核心字段是提问内容、回复内容和提问时间。它同时外键引用商品表和用户表，这就保证了每条留言都能找到对应的商品和提问人。卖家回复时更新reply_content和reply_at，用"回复内容是否为空"就能判断这条咨询是否已被处理，不需要额外维护一个状态字段。

收藏表favorite解决的是"用户和商品之间的多对多关系"。一个用户能收藏很多商品，一个商品也能被很多用户收藏，规范做法是拆出一张中间表favorite，每个收藏行为一行记录。我在(user_id, product_id)上加了联合唯一索引，保证同一个用户不能重复收藏同一个商品。

2.6 ER图关系线：一眼看清所有外键

虽然博文里不方便直接贴图，但ER图的关系可以先用表格理清楚，画图的时候照着连线就行。我整理了一份关系清单：

画图的时候，user和product之间那条"多对多收藏关系"不要直接连线，要先连到favorite表再连到product表，这是中间表的规范画法。

3. 完整DDL落地：建库、建表、外键约束逐步拆解

3.1 建库与前置约定

我选用 MySQL 8.0，字符集统一utf8mb4，排序规则用utf8mb4_unicode_ci，存储引擎全部用InnoDB。之所以强调统一，是因为外键关联的两张表如果字符集或引擎不一致，建表时会出现"Foreign key constraint is incorrectly formed"的报错，这类问题排查起来非常隐蔽。

CREATE DATABASE IF NOT EXISTS campus_market DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE campus_market;

3.2 基础表：分类表和用户表

先建分类表，再建用户表。这两张表不依赖其他表，属于整个外键链条里的"父表"。

CREATE TABLE `category` ( `category_id` INT NOT NULL AUTO_INCREMENT COMMENT '分类ID', `category_name` VARCHAR(50) NOT NULL COMMENT '分类名称', `sort_order` INT NOT NULL DEFAULT 0 COMMENT '排序权重，数值越大越靠前', `description` VARCHAR(255) DEFAULT NULL COMMENT '分类说明', PRIMARY KEY (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品分类表'; CREATE TABLE `user` ( `user_id` INT NOT NULL AUTO_INCREMENT COMMENT '用户ID', `student_no` VARCHAR(20) NOT NULL COMMENT '学号，校园实名场景建议唯一', `username` VARCHAR(30) NOT NULL COMMENT '登录账号', `nickname` VARCHAR(30) NOT NULL COMMENT '展示昵称', `password_hash` VARCHAR(64) NOT NULL COMMENT '密码哈希，禁止存明文', `phone` VARCHAR(20) DEFAULT NULL COMMENT '联系方式', `college` VARCHAR(50) DEFAULT NULL COMMENT '学院', `credit_score` INT NOT NULL DEFAULT 100 COMMENT '信用分，初始100，违约扣分', `role` ENUM('USER','ADMIN') NOT NULL DEFAULT 'USER' COMMENT '角色：USER/CUSTOMER 或管理员', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间', PRIMARY KEY (`user_id`), UNIQUE KEY `uk_student_no` (`student_no`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

学号和登录账号的唯一约束，在AI的第一版脚本里经常被漏掉。课程设计评审时，老师会专门看这类约束是不是齐全。

3.3 核心业务表：商品表

商品表同时引用用户表和分类表，建表时必须确认这两张父表已经创建成功。

CREATE TABLE `product` ( `product_id` INT NOT NULL AUTO_INCREMENT COMMENT '商品ID', `user_id` INT NOT NULL COMMENT '发布者ID，即卖家', `category_id` INT NOT NULL COMMENT '分类ID', `title` VARCHAR(100) NOT NULL COMMENT '商品标题', `description` TEXT COMMENT '商品详细描述', `price` DECIMAL(10,2) NOT NULL COMMENT '售价，单位元', `original_price` DECIMAL(10,2) DEFAULT NULL COMMENT '原价/参考价', `condition_level` ENUM('全新','几乎全新','轻微使用','明显使用痕迹') NOT NULL DEFAULT '轻微使用' COMMENT '成色', `image_url` VARCHAR(255) DEFAULT NULL COMMENT '商品图片地址', `status` ENUM('在售','已售出','下架') NOT NULL DEFAULT '在售' COMMENT '商品状态', `views` INT NOT NULL DEFAULT 0 COMMENT '浏览量', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '发布时间', `updated_at` DATETIME DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`product_id`), KEY `idx_product_user` (`user_id`), KEY `idx_product_category` (`category_id`), KEY `idx_product_status` (`status`), CONSTRAINT `fk_product_user` FOREIGN KEY (`user_id`) REFERENCES `user` (`user_id`) ON DELETE RESTRICT ON UPDATE CASCADE, CONSTRAINT `fk_product_category` FOREIGN KEY (`category_id`) REFERENCES `category` (`category_id`) ON DELETE RESTRICT ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='二手商品表';

这里的外键我用了ON DELETE RESTRICT，而不是ON DELETE CASCADE。一级分类被商品引用后不应该被直接删除，否则商品会失去分类归属；用户被商品引用后更不应该被删掉，否则交易记录就断了。宁可让程序先处理下线或禁用，也不能让数据库级联把业务数据连带清掉。

3.4 中间表和订单表：收藏、留言、订单

收藏表和留言表都同时依赖商品表和用户表，订单表同时依赖商品表和用户表，并且product_id有唯一约束。

CREATE TABLE `favorite` ( `favorite_id` INT NOT NULL AUTO_INCREMENT COMMENT '收藏ID', `user_id` INT NOT NULL COMMENT '收藏用户ID', `product_id` INT NOT NULL COMMENT '被收藏商品ID', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '收藏时间', PRIMARY KEY (`favorite_id`), UNIQUE KEY `uk_favorite_user_product` (`user_id`, `product_id`), KEY `idx_favorite_product` (`product_id`), CONSTRAINT `fk_favorite_user` FOREIGN KEY (`user_id`) REFERENCES `user` (`user_id`) ON DELETE RESTRICT ON UPDATE CASCADE, CONSTRAINT `fk_favorite_product` FOREIGN KEY (`product_id`) REFERENCES `product` (`product_id`) ON DELETE RESTRICT ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='收藏表'; CREATE TABLE `message` ( `message_id` INT NOT NULL AUTO_INCREMENT COMMENT '留言ID', `product_id` INT NOT NULL COMMENT '关联商品ID', `user_id` INT NOT NULL COMMENT '提问用户ID', `content` VARCHAR(500) NOT NULL COMMENT '咨询内容', `reply_content` VARCHAR(500) DEFAULT NULL COMMENT '卖家回复内容', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '提问时间', `reply_at` DATETIME DEFAULT NULL COMMENT '回复时间', PRIMARY KEY (`message_id`), KEY `idx_message_product` (`product_id`), KEY `idx_message_user` (`user_id`), CONSTRAINT `fk_message_product` FOREIGN KEY (`product_id`) REFERENCES `product` (`product_id`) ON DELETE RESTRICT ON UPDATE CASCADE, CONSTRAINT `fk_message_user` FOREIGN KEY (`user_id`) REFERENCES `user` (`user_id`) ON DELETE RESTRICT ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='留言咨询表'; CREATE TABLE `orders` ( `order_id` INT NOT NULL AUTO_INCREMENT COMMENT '订单ID', `order_no` VARCHAR(32) NOT NULL COMMENT '业务订单号', `product_id` INT NOT NULL COMMENT '商品ID', `buyer_id` INT NOT NULL COMMENT '买家ID', `seller_id` INT NOT NULL COMMENT '卖家ID', `product_title` VARCHAR(100) NOT NULL COMMENT '商品标题快照', `deal_price` DECIMAL(10,2) NOT NULL COMMENT '成交价，下单时快照', `status` ENUM('待确认','已完成','已取消') NOT NULL DEFAULT '待确认' COMMENT '订单状态', `remark` VARCHAR(255) DEFAULT NULL COMMENT '订单备注', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '下单时间', `completed_at` DATETIME DEFAULT NULL COMMENT '完成时间', PRIMARY KEY (`order_id`), UNIQUE KEY `uk_order_no` (`order_no`), UNIQUE KEY `uk_order_product` (`product_id`), KEY `idx_order_buyer` (`buyer_id`), KEY `idx_order_seller` (`seller_id`), CONSTRAINT `fk_order_product` FOREIGN KEY (`product_id`) REFERENCES `product` (`product_id`) ON DELETE RESTRICT ON UPDATE CASCADE, CONSTRAINT `fk_order_buyer` FOREIGN KEY (`buyer_id`) REFERENCES `user` (`user_id`) ON DELETE RESTRICT ON UPDATE CASCADE, CONSTRAINT `fk_order_seller` FOREIGN KEY (`seller_id`) REFERENCES `user` (`user_id`) ON DELETE RESTRICT ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='交易订单表';

订单表的seller_id和buyer_id都引用同一张user表，这在ER图里会画出两条从 user 指向 orders 的线，一条标"买家"，一条标"卖家"，这是很常见的一对多关系，不冲突。外键约束名一定要用fk_order_buyer和fk_order_seller区分，如果只写fk_order_user，会让人分不清到底是买家还是卖家。

4. 每张表不低于10条数据的DML：保姆级填充

4.1 插入顺序：为什么必须先插父表再插子表

外键约束的作用是保证引用完整性，副作用就是INSERT必须按照"父表在前，子表在后"的顺序执行。如果你先插商品表，再插用户表，数据库会直接报外键错误，因为商品引用的user_id在用户表里还不存在。

我这边的插入顺序是：分类表 → 用户表 → 商品表 → 收藏表 → 留言表 → 订单表。收藏、留言、订单都依赖商品和用户，所以放在最后。

4.2 基础数据：分类表和用户表的DML

分类表我给了10条，正好覆盖校园二手的高频品类。

INSERT INTO `category` (`category_id`, `category_name`, `sort_order`, `description`) VALUES (1, '书籍教材', 100, '教材、教辅、考试资料'), (2, '数码影音', 90, '手机、耳机、显示器、相机等'), (3, '生活用品', 80, '台灯、水杯、收纳等日常用品'), (4, '运动器材', 70, '球拍、球类、健身器材'), (5, '乐器', 60, '吉他、尤克里里、键盘'), (6, '服饰鞋包', 50, '衣服、鞋子、背包'), (7, '美妆个护', 40, '护肤品、化妆品、个护'), (8, '宿舍电器', 30, '冰箱、电扇、除湿盒等'), (9, '交通出行', 20, '自行车、电动车、滑板'), (10, '游戏周边', 10, '桌游、手办、卡牌');

用户表给了12条，其中第一条是管理员账号，其余是普通学生。密码字段是占位哈希值，真正跑系统前必须替换成BCrypt等算法的真实哈希。

INSERT INTO `user` (`user_id`, `student_no`, `username`, `nickname`, `password_hash`, `phone`, `college`, `credit_score`, `role`, `created_at`) VALUES (1, '2024010101', 'u_001', '雨后管理员', 'hashed_demo_001', '13800000001', '计算机学院', 100, 'ADMIN', '2025-03-01 10:00:00'), (2, '2024010102', 'u_002', '雨后的猫', 'hashed_demo_002', '13800000002', '计算机学院', 100, 'USER', '2025-03-02 10:00:00'), (3, '2024010103', 'u_003', '走廊尽头', 'hashed_demo_003', '13800000003', '外国语学院', 98, 'USER', '2025-03-03 10:00:00'), (4, '2024010104', 'u_004', '图书馆守夜人', 'hashed_demo_004', '13800000004', '经管学院', 100, 'USER', '2025-03-04 10:00:00'), (5, '2024010105', 'u_005', '三分糖去冰', 'hashed_demo_005', '13800000005', '计算机学院', 100, 'USER', '2025-03-05 10:00:00'), (6, '2024010106', 'u_006', '球鞋会发光', 'hashed_demo_006', '13800000006', '体育学院', 96, 'USER', '2025-03-06 10:00:00'), (7, '2024010107', 'u_007', '深夜食堂常客', 'hashed_demo_007', '13800000007', '外国语学院', 100, 'USER', '2025-03-07 10:00:00'), (8, '2024010108', 'u_008', '码农不打烊', 'hashed_demo_008', '13800000008', '软件学院', 100, 'USER', '2025-03-08 10:00:00'), (9, '2024010109', 'u_009', '猫猫教信徒', 'hashed_demo_009', '13800000009', '艺术设计学院', 100, 'USER', '2025-03-09 10:00:00'), (10, '2024010110', 'u_010', '阿瓦达索命', 'hashed_demo_010', '13800000010', '电气学院', 99, 'USER', '2025-03-10 10:00:00'), (11, '2024010111', 'u_011', '早八人', 'hashed_demo_011', '13800000011', '机械学院', 100, 'USER', '2025-03-11 10:00:00'), (12, '2024010112', 'u_012', '食堂扫地僧', 'hashed_demo_012', '13800000012', '化学学院', 100, 'USER', '2025-03-12 10:00:00');

注意看，u_001的管理员账号昵称我特意取了"雨后管理员"，避免和真实人物撞名，演示数据最好都用这种一眼能看出是虚构的昵称。

4.3 商品数据：12条贴近校园场景的示例

商品数据我准备了12条，分布在8个分类里，覆盖教材、数码、生活、乐器、交通等常见二手交易品类。状态字段和后面的订单数据是对应的：已售出的商品对应"已完成"订单，在售的商品没有订单或者只有"待确认"订单。

INSERT INTO `product` (`product_id`, `user_id`, `category_id`, `title`, `description`, `price`, `original_price`, `condition_level`, `image_url`, `status`, `views`, `created_at`) VALUES (1, 2, 1, '高等数学教材 第7版 下册', '有少量铅笔笔记，不影响阅读，期末复习可用', 8.00, 45.00, '轻微使用', '/img/book_math.jpg', '已售出', 120, '2025-04-02 09:00:00'), (2, 3, 1, '考研英语历年真题', '涵盖近十年真题，答案齐全，无水印', 15.00, 68.00, '轻微使用', '/img/book_english.jpg', '在售', 80, '2025-04-05 10:10:00'), (3, 4, 2, '蓝牙耳机', '九成新，充电仓正常，续航还可以', 120.00, 399.00, '几乎全新', '/img/earphone.jpg', '在售', 260, '2025-04-08 14:20:00'), (4, 5, 2, '便携显示器 15.6英寸', 'IPS屏，宿舍外接电脑用，无坏点', 480.00, 899.00, '轻微使用', '/img/monitor.jpg', '已售出', 95, '2025-04-10 11:30:00'), (5, 6, 9, '山地自行车', '26寸，变速正常，刹车刚换过线', 260.00, 1200.00, '明显使用痕迹', '/img/bike.jpg', '已售出', 340, '2025-04-12 08:40:00'), (6, 7, 5, '尤克里里 23寸', '桃花心木，送一个调音器，适合入门', 120.00, 360.00, '几乎全新', '/img/ukulele.jpg', '在售', 55, '2025-04-13 16:00:00'), (7, 8, 10, '卡牌桌游套装', '聚会用的卡牌桌游，卡牌齐全，盒子有磕碰', 30.00, 129.00, '轻微使用', '/img/boardgame.jpg', '在售', 77, '2025-04-15 20:00:00'), (8, 9, 8, '宿舍小冰箱', '迷你款，冷藏正常，临近毕业搬家出', 180.00, 460.00, '轻微使用', '/img/fridge.jpg', '已售出', 210, '2025-04-16 13:00:00'), (9, 10, 4, '网球拍', '入门款，拍线建议买后更换，手感还在', 45.00, 210.00, '明显使用痕迹', '/img/racket.jpg', '在售', 32, '2025-04-17 17:30:00'), (10, 11, 6, '羽绒服 175码', '洗过两次，保暖没问题，不跑毛', 80.00, 500.00, '几乎全新', '/img/coat.jpg', '在售', 150, '2025-04-18 12:00:00'), (11, 12, 3, '护眼台灯', '三档调光，宿舍神器，USB供电', 12.00, 89.00, '轻微使用', '/img/lamp.jpg', '在售', 99, '2025-04-19 19:00:00'), (12, 3, 2, '科学计算器', '函数型计算器，考研党自用，按键灵敏', 25.00, 98.00, '轻微使用', '/img/calculator.jpg', '在售', 66, '2025-04-20 09:30:00');

注意商品12的卖家是user_id=3，同一个用户可以发布多件商品，这就是user表对product表的1对N关系在数据层的直接体现。商品图片字段我用了/img/xxx.jpg这种相对路径，这是为了贴合Web项目部署场景，你跑本地项目时改成实际路径即可。

4.4 收藏数据和留言数据

收藏表10条。这里我特意让同一个商品"蓝牙耳机"被两个不同用户收藏，这能演示收藏表的联合唯一约束：同一个用户对同一个商品只能收藏一次，但不同用户可以对同一个商品分别收藏。

INSERT INTO `favorite` (`favorite_id`, `user_id`, `product_id`, `created_at`) VALUES (1, 4, 1, '2025-04-21 08:30:00'), (2, 7, 3, '2025-04-22 09:00:00'), (3, 5, 6, '2025-04-23 10:00:00'), (4, 2, 7, '2025-04-24 11:00:00'), (5, 9, 9, '2025-04-25 12:00:00'), (6, 3, 10, '2025-04-26 13:00:00'), (7, 10, 12, '2025-04-27 14:00:00'), (8, 6, 2, '2025-04-28 15:00:00'), (9, 11, 3, '2025-04-29 16:00:00'), (10, 8, 11, '2025-04-30 17:00:00');

留言表10条，部分是卖家已回复的，部分是未回复的。这些数据在后续做"我的咨询"列表时可以直接用。

INSERT INTO `message` (`message_id`, `product_id`, `user_id`, `content`, `reply_content`, `created_at`, `reply_at`) VALUES (1, 1, 4, '请问书上有笔记吗？', '有少量铅笔标注', '2025-05-01 10:00:00', '2025-05-01 12:00:00'), (2, 3, 7, '耳机充电仓有磨损吗？', NULL, '2025-05-02 09:00:00', NULL), (3, 5, 6, '刹车灵不灵？', '刚换过刹车线', '2025-05-03 10:20:00', '2025-05-03 14:00:00'), (4, 6, 9, '能不能少一点？', '最低100，送调音器', '2025-05-04 15:30:00', '2025-05-04 16:10:00'), (5, 8, 11, '冰箱制冷怎么样？', '制冷正常，冷藏室无冰', '2025-05-05 09:10:00', '2025-05-05 11:00:00'), (6, 9, 5, '网球拍拍线松了吗？', NULL, '2025-05-06 14:40:00', NULL), (7, 10, 8, '羽绒服是什么尺码？', '175/92A', '2025-05-07 18:20:00', '2025-05-07 20:00:00'), (8, 12, 6, '计算器是科学计算器吗？', '是，函数型，不是简单四则运算', '2025-05-08 08:50:00', '2025-05-08 09:30:00'), (9, 2, 4, '真题更新到哪一年？', '到2024年', '2025-05-09 10:00:00', '2025-05-09 11:00:00'), (10, 7, 2, '桌游配件齐全吗？', NULL, '2025-05-10 13:30:00', NULL);

4.5 订单数据：状态与商品状态保持一致

订单表是全套数据里最容易和商品状态"打架"的地方。商品1、4、5、8在商品表里是"已售出"，所以对应的4条订单我设置成"已完成"，并且completed_at有值。商品3、6、7、9、10、12虽然在售，但已经有人下单了，订单状态是"待确认"。这样设计，业务逻辑才说得通。

INSERT INTO `orders` (`order_id`, `order_no`, `product_id`, `buyer_id`, `seller_id`, `product_title`, `deal_price`, `status`, `remark`, `created_at`, `completed_at`) VALUES (1, '20250508001', 1, 4, 2, '高等数学教材 第7版 下册', 8.00, '已完成', NULL, '2025-05-08 10:00:00', '2025-05-09 12:00:00'), (2, '20250508002', 4, 6, 5, '便携显示器 15.6英寸', 450.00, '已完成', '讲价30元', '2025-05-09 09:30:00', '2025-05-10 15:00:00'), (3, '20250508003', 5, 7, 6, '山地自行车', 250.00, '已完成', '线下自提', '2025-05-10 18:00:00', '2025-05-11 09:30:00'), (4, '20250508004', 8, 11, 9, '宿舍小冰箱', 160.00, '已完成', '宿舍楼门口交易', '2025-05-11 10:00:00', '2025-05-12 17:20:00'), (5, '20250509001', 3, 2, 4, '蓝牙耳机', 120.00, '待确认', NULL, '2025-05-12 12:00:00', NULL), (6, '20250509002', 6, 9, 7, '尤克里里 23寸', 110.00, '待确认', NULL, '2025-05-12 14:30:00', NULL), (7, '20250509003', 7, 3, 8, '卡牌桌游套装', 30.00, '待确认', '当面交易', '2025-05-13 09:00:00', NULL), (8, '20250509004', 9, 5, 10, '网球拍', 45.00, '待确认', NULL, '2025-05-13 11:20:00', NULL), (9, '20250509005', 10, 8, 11, '羽绒服 175码', 70.00, '待确认', NULL, '2025-05-14 16:00:00', NULL), (10, '20250509006', 12, 6, 3, '科学计算器', 25.00, '待确认', NULL, '2025-05-14 19:30:00', NULL);

注意订单2的成交价是450，而商品4的挂牌价是480，我刻意做了这个差异，用来演示"允许讲价"的场景。正是因为订单表有deal_price快照，才能保留实际成交金额，而不是永远读取商品表里的价格。

5. AI辅助开发实操：提示词怎么给、坑怎么躲

5.1 一份可以直接复制的AI提示词

既然项目标题强调"在AI工具的辅助下"完成，那这部分才是你真正能提高效率的技巧。很多同学让AI写数据库脚本，只丢一句话"帮我设计一个二手交易系统"，出来的东西基本没法直接用，因为需求太模糊，AI只能给你一份泛泛的模板。

我实际用下来比较稳的提示词是这个思路，你可以直接复制改造：

你是资深数据库设计工程师。请为「校园二手物品交易系统」设计 MySQL 8.0 数据库，要求如下： 1. 业务描述：在校学生可以发布二手物品（标题、描述、价格、成色、图片），按分类展示；其他学生可以浏览、收藏、留言咨询、下单购买；平台有管理员管理分类和违规商品。 2. 需要输出：ER图关系文本说明、完整DDL（含建库语句）、每张表不低于10条的DML示例数据、外键关系清单。 3. 硬性要求： - 每张表必须有主键，价格/金额一律用 DECIMAL(10,2)，禁止 FLOAT； - 所有外键必须命名，格式为 fk_子表_父表，并声明级联策略； - 订单表必须冗余商品名称和成交价格快照； - 同一商品不能同时产生两笔有效订单； - DML 插入顺序必须符合外键依赖，先父表后子表，不能出现父表不存在的主键值； - 字符集统一 utf8mb4，存储引擎 InnoDB； - 每张表至少 10 条数据，数据要贴近校园二手场景。

这个提示词的核心不是让AI"生成所有代码"，而是把约束条件写清楚。AI对"合理默认"的理解和你不一样，你必须把外键命名规范、DECIMAL要求、快照字段、插入顺序这些硬性规则全部明确写进去，它输出的东西才能达到能直接跑的程度。

5.2 AI生成DDL最常踩的四个坑

我见过好几份AI生成的课程设计数据库脚本，跑下来问题高度集中在四个点。

第一个坑是价格字段用了FLOAT。不知道为什么，很多模型默认给金额类字段用FLOAT，这可能是训练数据里电商示范代码太多造成的。你要在提示词里反复强调"禁止FLOAT"，生成后再检查一遍。

第二个坑是外键约束名混乱。多张表都引用user_id，AI如果不显式命名，可能自动生成重复约束名，或者导出脚本时外键名对不上。统一用fk_子表_父表规则可以规避这个问题。

第三个坑是DML数据里的外键引用值对不上。AI在生成商品数据时可能随便填了一个category_id=99，但分类表只到10，一跑就报错。这个在5.3里我会给一个完整的排查案例。

第四个坑是级联策略一刀切。AI默认给所有外键加ON DELETE CASCADE，结果删除一个分类把整个分类下的商品全部级联删掉，删除一个用户把该用户的所有订单抹平。交易系统里这种操作是事故级别的。业务数据宁可留脏，不能没痕迹。我全部改成了ON DELETE RESTRICT，只保留ON UPDATE CASCADE。

5.3 外键报错的完整排查链路

我印象最深的一次排错，是某同学让AI新增了订单表的DML，第一条INSERT就报了下面这个错误：

ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`campus_market`.`orders`, CONSTRAINT `fk_order_buyer` FOREIGN KEY (`buyer_id`) REFERENCES `user` (`user_id`))

这个报错看起来复杂，其实逻辑很直接：orders表里的buyer_id在user表里找不到对应记录。我当时让他先查用户表：

SELECT user_id FROM user;

结果用户表只有12条数据，AI生成的订单里有一个buyer_id=99，这值根本不存在。原因就是AI在生成订单数据时，没有去核对用户表里实际有哪些ID，而是凭感觉填了一堆"看起来合理"的外键值。

排查这类问题最快的办法不是肉眼找，而是直接跑一条"找孤儿记录"的SQL。我常用的自检语句是这样的：

-- 检查订单表是否存在用户表里不存在的买家 SELECT 'orders_buyer' AS src, COUNT(*) AS mismatch FROM orders o LEFT JOIN user u ON o.buyer_id = u.user_id WHERE u.user_id IS NULL UNION ALL -- 检查订单表是否存在商品表里不存在的商品 SELECT 'orders_product', COUNT(*) FROM orders o LEFT JOIN product p ON o.product_id = p.product_id WHERE p.product_id IS NULL UNION ALL -- 检查商品表是否存在分类表里不存在的分类 SELECT 'product_category', COUNT(*) FROM product p LEFT JOIN category c ON p.category_id = c.category_id WHERE c.category_id IS NULL;

这条查询如果任何一行的mismatch不是0，就说明数据里存在外键悬空。把这些悬空值替换成父表里真实存在的ID，问题就解决了。这个自检SQL在你给AI出题后、正式跑业务前，强烈建议先执行一遍。

5.4 把AI草稿变成能上交的ER图

ER图是课程设计的硬性提交物，AI工具在这个环节能帮上忙，但不能完全代劳。我的做法是：让AI先生成关系清单，就是2.6节那种表格，然后再打开绘图工具手动画一遍。

画图时注意几个要点：每个实体框里放主键和核心字段即可，不要把全部字段堆上去。关系线上标注基数，比如1 : N或N : M。收藏表这种中间表，要把两条关系线分别连到用户表和商品表，不能跳过它直连。外键字段在实体框里单独列出来，或者用星号标记，方便老师一眼认出。如果AI能输出可导入的绘图文件格式，那可以直接导入后手动调整布局，比自己从零画省很多时间。

我自己的经验是，AI生成的ER图草稿往往存在"关系线指向错误"或"基数标注缺失"的问题，人工检查一遍是必须的，特别是在orders表上有两条外键指向user表的情况下，要确保两条线分别标注"买家"和"卖家"。

我在实际项目里的收尾习惯

这套表设计完成后，后续写Java或Python后端接口时几乎不需要再改表结构，这是我最满意的地方。数据库设计稳定的收益会在后面持续放大，代码写起来非常顺畅。说两个最后的小建议。

第一个，外键关系不要只靠建表语句表达，建议导入数据库后用下面这条SQL再确认一遍外键清单，防止AI生成的脚本漏掉约束：

SELECT table_name AS child_table, constraint_name AS fk_name, referenced_table_name AS parent_table FROM information_schema.referential_constraints WHERE constraint_schema = 'campus_market' ORDER BY child_table;

第二个，所有password_hash的示例数据，跑真实项目时一定要换成加密哈希，不要用hashed_demo_001这种占位符直接上线。数据表里所有时间字段，如果演示数据里写的是固定时间，实际使用时应改为NOW()或直接依赖数据库默认值。

AI工具可以让效率翻倍，但表结构设计这件事的"设计决策权"还是要攥在自己手里。你能把外键逻辑、快照字段、状态一致性讲清楚，课程设计的答辩这一关基本就稳了。