JavaEE小Demo数据库设计实战：从建库建表到DDL版本管理-北京尧图网络

1. 一个空壳Demo背后数据库设计到底该做到什么程度做JavaEE的小Demo很多人第一反应是打开IDE、建Maven工程、拉Spring Boot骨架然后写Controller、写Service一路顺风顺水等到要连数据库了突然卡住——表怎么建字段怎么定主外键要不要加字符集选哪个索引加不加这些问题在正式项目里通常有DBA或者架构师兜底但在自己练手的小Demo里全得自己拍板。我见过太多人在这步直接糊弄过去随便建两张表字段全用varchar(255)主键用自增int外键一个不加然后跑通了就觉得自己会了。结果换一个Demo同样的坑再踩一遍。这篇内容就是围绕JavaEE小Demo的数据库建立这个看似基础、实则暗藏大量决策点的环节展开。它不是什么高深的技术专题而是一个从零把Demo数据库搭到能支撑后续CRUD、能经得起自己回头改的程度的完整过程记录。适合两类人看一类是刚学完JDBC或MyBatis、准备动手做第一个带持久层的JavaEE练手项目的人另一类是做过几个Demo但每次建库都凭感觉、想把这套流程固化下来的人。我会把建库建表时的取舍逻辑、字段设计的常见误区、字符集与排序规则的坑、以及小Demo场景下该省和不该省的边界讲清楚让你下次打开数据库客户端时不再靠猜。需要先说明一点小Demo的数据库和正式生产库在设计目标上是不同的。生产库要考虑高并发、分库分表、读写分离、审计字段、软删除、版本迁移而Demo库的核心目标是结构清晰、能快速迭代、能直观体现业务关系。把生产级的那套全搬过来一个练手项目光建表就能写两百行SQL改一次字段要动三四个地方反而拖慢学习节奏。所以下面所有的建议都建立在这是个小Demo这个前提上我会明确告诉你哪些地方可以偷懒、哪些地方偷懒会付出代价。2. 建库之前先想清楚Demo的业务模型怎么落到表结构上2.1 从要演示什么功能倒推需要几张表很多人建表的顺序是反的先打开客户端想着我要建个用户表然后凭直觉加字段。正确的顺序应该是先问自己——这个Demo要演示哪几个核心功能每个功能涉及哪些实体实体之间是什么关系举个最常见的场景一个带登录和列表展示的练手Demo。功能拆下来无非三块用户注册登录、某个业务对象比如文章、商品、订单随便挑一个的增删改查、以及两者的归属关系。对应到表最少三张用户表、业务主表、以及如果业务对象需要分类再加一张分类表。三张表足够撑起一个能演示登录鉴权数据列表条件筛选的完整链路。我建议在纸上或者文档里先画一个极简的实体关系草图不用工具手写就行。画的时候只标三样东西实体名、关键属性、实体之间的连线一对一、一对多、多对多。这个草图决定了后面建表的数量和关联方式比直接上手写SQL靠谱得多。草图阶段改一行字比建完表再改结构省事十倍。2.2 一对多和多对多在小Demo里的落地取舍实体关系里最容易让人犹豫的是多对多。比如文章和标签一个文章多个标签一个标签属于多个文章标准做法是建一张中间表两个外键组成联合主键。这个做法没错但在小Demo里要不要这么做取决于你要不要演示按标签筛选文章这个功能。如果要中间表老老实实建如果只是展示标签文字、不做反向查询那完全可以在文章表里存一个逗号分隔的标签字符串省掉一张表和一次join。这里的关键判断标准是这个关系需不需要被独立查询。需要就建中间表不需要就冗余存储。小Demo里冗余存储的代价很低因为数据量小、没有一致性要求而多一张表就多一套Mapper、多一层关联查询对练手阶段的心智负担是实打实的。我在早期做Demo时吃过亏为了规范硬建中间表结果标签功能根本没做筛选那张表从头到尾没被查过纯属摆设。一对多则几乎没有取舍空间外键字段必须落在多的那一侧。比如用户和文章user_id放在文章表里。这里唯一要决定的是这个外键字段要不要加数据库层面的外键约束。我的建议是小Demo里不加物理外键只在逻辑上保证关联。原因后面第4节会详细说。2.3 表名和字段名的命名约定一开始就定死命名这件事单看一张表无所谓表一多就显出混乱。我见过同一个Demo里用户表叫user、文章表叫t_article、分类表叫category_info三种风格并存写SQL时每次都要想一下这张表到底叫什么。所以建库第一步先把命名约定写下来后面所有表严格照办。我常用的约定是这样的表名统一小写下划线风格不加t_前缀小Demo没必要前缀是给大型系统做区分用的字段名同样小写下划线主键统一叫id外键统一叫关联表名单数_id比如user_id、category_id布尔类型字段用is_开头比如is_deleted、is_active时间字段用created_at、updated_at这种带_at后缀的写法。这套约定不是唯一正确的但一旦定下来就不要再变因为后面写实体类、写Mapper、写前端字段映射全靠这套名字对齐中途改名会牵连一大片。提示命名约定最好在建第一张表之前就写进项目根目录的一个markdown文件里哪怕只有五行。Demo做完回头看这份约定本身就是一份可复用的资产。3. 字段设计类型、长度、默认值每一个都有代价3.1 主键用自增还是用业务字段小Demo的答案很明确主键选型是建表时第一个要拍板的事。常见选项有三个自增整数、UUID字符串、业务字段比如手机号、邮箱。小Demo场景下我几乎无条件选自增整数理由有三条。第一自增整数在数据库里存储效率最高索引结构紧凑join时性能好虽然Demo数据量小感知不到但养成习惯没坏处。第二自增主键对调试极其友好看日志里id3就知道是第三条数据UUID那一长串在日志里根本对不上号。第三自增主键不需要应用层生成数据库自己管少一层逻辑。UUID的唯一优势是分布式环境下不冲突但小Demo是单库单实例这个优势用不上反而带来存储膨胀和可读性差的缺点。业务字段做主键的问题更明显手机号可能变、邮箱可能改一旦主键值变了所有引用它的外键都要跟着改这是自找麻烦。所以主键就用id BIGINT AUTO_INCREMENT PRIMARY KEY简单直接。3.2 varchar长度别拍脑袋按真实数据上限留余量字段长度是最容易被随手填的地方很多人习惯性写varchar(255)觉得够大就行。255这个数字本身没什么魔力它只是MySQL早期版本里一个索引长度相关的历史遗留值。真正该做的是按字段的实际含义估一个上限再留一点余量。比如用户名一般限制在20个字符以内那字段就定varchar(32)留出余量应对未来可能放宽规则密码存的是哈希值常见哈希算法输出固定长度比如BCrypt是60个字符那就定varchar(64)或varchar(100)不要用255浪费邮箱地址理论上最长可以很长但实际业务里超过100个字符的极少定varchar(128)足够文章标题定varchar(200)正文用TEXT或MEDIUMTEXT。这里有个实操细节varchar的长度在MySQL里影响的是行内存储的最大字节数utf8mb4编码下每个字符最多占4字节所以varchar(32)实际可能占128字节。小Demo数据量小这个差异无所谓但养成按需定长的习惯等以后数据量上来了不会手忙脚乱。另外长度定得合理还有一个隐性好处应用层的参数校验和数据库的字段长度能对上不会出现前端校验通过、入库被截断的尴尬。3.3 时间字段、布尔字段和金额字段的类型陷阱时间字段的坑主要集中在用哪种类型和存不存时区上。小Demo里我统一用DATETIME不用TIMESTAMP。原因是TIMESTAMP有2038年上限而且它的时区转换行为依赖数据库服务器配置换个环境跑出来的时间可能不一样调试时非常迷惑。DATETIME存的是字面值写进去什么读出来什么行为可预期。created_at和updated_at两个字段基本是标配created_at在插入时由应用层赋值或数据库默认值填充updated_at在每次更新时刷新。布尔字段在MySQL里没有真正的boolean类型BOOLEAN只是TINYINT(1)的别名。所以is_deleted这类字段实际存的是0和1。这里要注意的是默认值is_deleted默认0is_active默认1这些默认值一定要在DDL里写死不要依赖应用层每次插入都记得传否则某次漏传就会变成NULL而NULL在条件判断里的行为和三值逻辑会让查询结果出乎意料。金额字段是另一个高频陷阱。用FLOAT或DOUBLE存金额浮点精度问题会导致0.10.2不等于0.3这种经典问题对账时能让人抓狂。正确做法是用DECIMAL比如DECIMAL(10,2)表示总共10位、小数2位最大能存到99999999.99。小Demo里如果涉及价格、余额一律DECIMAL不要图省事用double。字段类型推荐写法常见错误写法后果主键BIGINT AUTO_INCREMENTVARCHAR(36)存UUID索引膨胀、日志难读用户名VARCHAR(32)VARCHAR(255)浪费空间、校验脱节时间DATETIMETIMESTAMP时区行为不可预期布尔TINYINT(1) DEFAULT 0无默认值NULL导致查询异常金额DECIMAL(10,2)DOUBLE浮点精度丢失3.4 该不该加created_at和updated_at小Demo也别省有人觉得小Demo不需要审计字段建表时省掉created_at和updated_at等后面想按时间排序了再ALTER TABLE加。这个省其实不划算。加两个DATETIME字段的成本几乎为零但它们在调试和演示时的价值很高列表默认按创建时间倒序是最自然的展示顺序排查问题时看一眼updated_at就知道数据最后被动过没有演示最近更新功能时直接就有数据可用。更重要的是这两个字段能帮你养成一个思维习惯——任何一张业务表都应该有这条数据什么时候来的、什么时候变的这个维度。这个习惯在Demo阶段建立起来以后做正式项目时不会漏。所以我的做法是只要是业务表created_at和updated_at一律加上默认值分别设为CURRENT_TIMESTAMP和CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP让数据库自己维护应用层不用管。4. 外键约束、索引、字符集三个最容易被规范带偏的地方4.1 物理外键在小Demo里为什么建议不加数据库教科书和很多规范文档都会强调外键约束的重要性说它能保证引用完整性。这话在正式项目里成立但在小Demo里物理外键带来的麻烦往往大于收益。第一个麻烦是插入和删除的顺序限制。有了外键约束插入文章前必须先有对应用户删除用户前必须先删掉他所有文章否则数据库直接报错。Demo阶段经常需要清空数据重来或者手动插测试数据外键约束会让这些操作变得束手束脚每次都要按依赖顺序来。第二个麻烦是测试数据构造。想单独测文章列表功能得先造一个用户再拿它的id去造文章链路一长测试脚本就复杂了。我的做法是外键字段照建但DDL里不写FOREIGN KEY约束关联关系靠应用层保证。这样插入顺序自由、清数据自由而关联的正确性通过Service层的逻辑和查询时的join来维护。等以后真要做正式项目再根据实际需要决定加不加物理外键——那时候你有足够的经验判断这个取舍。注意不加物理外键不等于可以乱来。外键字段的类型必须和被引用表的主键类型完全一致都是BIGINT命名必须规范user_id这些是逻辑关联的基础不能省。4.2 索引Demo阶段只加两类多一个都是负担索引的诱惑在于加了好像更专业但小Demo里数据量往往只有几十上百条全表扫描和走索引的耗时差异根本感知不到而多余的索引会拖慢写入、增加维护成本。所以我的原则是Demo阶段只加两类索引其余一律不加。第一类是主键索引建表时自动就有不用管。第二类是唯一索引用在真正需要唯一约束的字段上比如用户表的username和email。唯一索引的价值不在查询加速而在数据校验——它能从数据库层面挡住重复注册这是应用层校验之外的一道保险值得加。除此之外像按创建时间排序这种需求几十条数据全表扫加排序毫秒级完成加索引纯属浪费。如果Demo后期数据量涨到几千条、某个列表查询明显变慢再针对那个查询的where条件加索引也不迟。索引应该是被性能问题逼出来的而不是提前预防出来的这个思路在小Demo阶段尤其适用。4.3 字符集选utf8mb4排序规则别用默认的字符集这件事一句话建库建表时显式指定utf8mb4不要依赖数据库默认值。MySQL早期版本的默认字符集是latin1后来改成utf8其实是utf8mb3最多3字节而utf8mb3存不了emoji和一些生僻字插入时会报错或乱码。utf8mb4才是完整的4字节UTF-8实现现在新建库没有理由不用它。排序规则collation跟着字符集走utf8mb4对应的常用排序规则是utf8mb4_general_ci和utf8mb4_unicode_ci。前者速度快但不完全符合Unicode排序标准后者更准确但稍慢。小Demo里两者都行我一般用utf8mb4_general_ci因为够用且兼容性好。关键是建库时就定好建表时继承不要出现库是utf8mb4、表是utf8mb3这种混搭混搭会导致join时字符集转换轻则慢重则报Illegal mix of collations错误。建库语句大概长这样CREATE DATABASE demo_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci;建表时如果不显式指定表会继承库的字符集所以库定对了表一般不会错。但如果你是从别处复制建表语句一定要检查里面有没有CHARSETutf8这种旧写法有就改成utf8mb4。5. 从建库到建表的完整落地一份可直接抄的DDL与执行顺序5.1 建库建表的执行顺序与依赖处理有了前面的设计决策落地就是按顺序执行SQL。顺序上有个基本原则被引用的表先建引用别人的表后建。比如用户表被文章表引用就先建用户表分类表被文章表引用就先建分类表文章表最后建。虽然我们不加物理外键建表顺序其实无所谓但保持这个习惯能让DDL读起来有逻辑也方便以后真要加外键时不用调整顺序。具体到一个三表Demo用户、分类、文章执行顺序是建库 → 切库 → 建用户表 → 建分类表 → 建文章表 → 插入种子数据。种子数据也要按同样顺序插先插用户和分类再插文章因为文章要引用前两者的id。5.2 一份三表Demo的完整DDL参考下面这份DDL是我常用的模板字段和类型都按前面讲的规则来可以直接改改表名就用CREATE DATABASE IF NOT EXISTS demo_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE demo_db; CREATE TABLE IF NOT EXISTS user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(32) NOT NULL, password VARCHAR(100) NOT NULL, email VARCHAR(128) DEFAULT NULL, is_active TINYINT(1) NOT NULL DEFAULT 1, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_username (username), UNIQUE KEY uk_email (email) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE IF NOT EXISTS category ( id BIGINT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(32) NOT NULL, sort_order INT NOT NULL DEFAULT 0, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE IF NOT EXISTS article ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL, category_id BIGINT DEFAULT NULL, title VARCHAR(200) NOT NULL, content MEDIUMTEXT, view_count INT NOT NULL DEFAULT 0, is_deleted TINYINT(1) NOT NULL DEFAULT 0, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这份DDL里有几个细节值得单独说。IF NOT EXISTS是为了让脚本可以重复执行Demo阶段经常要推倒重来有这个判断就不用每次先手动drop。ENGINEInnoDB显式指定存储引擎虽然现在MySQL默认就是InnoDB但写出来更明确也避免某些环境默认引擎不同带来的意外。uk_email唯一索引允许NULL值重复MySQL的唯一索引对NULL不生效所以email设成DEFAULT NULL这样多个用户不填邮箱不会冲突这个行为要心里有数。5.3 种子数据怎么造才能让Demo一跑起来就有东西看建完表空着跑起来页面一片空白演示效果很差。所以建表之后顺手插几条种子数据是Demo完整度的一部分。种子数据的原则是覆盖主要展示场景数量少而典型。比如用户插两条一条正常、一条is_active0用来演示禁用状态分类插三条覆盖不同sort_order文章插五条分属不同用户和分类其中一条is_deleted1用来验证软删除过滤逻辑是否生效。这样一跑起来列表有数据、筛选有结果、边界情况也有样本调试效率高很多。INSERT INTO user (username, password, email) VALUES (alice, $2a$10$abcdefghijklmnopqrstuv, aliceexample.com), (bob, $2a$10$zyxwvutsrqponmlkjihgfe, NULL); INSERT INTO category (name, sort_order) VALUES (技术, 1), (生活, 2), (随笔, 3); INSERT INTO article (user_id, category_id, title, content, view_count) VALUES (1, 1, 第一篇技术文章, 正文内容……, 120), (1, 2, 生活记录一则, 正文内容……, 35), (2, 1, 另一篇技术文章, 正文内容……, 88), (2, 3, 随手写写, 正文内容……, 12), (1, 1, 已删除的测试文章, 正文内容……, 0);密码字段这里存的是哈希占位串实际使用时由应用层用BCrypt等算法生成不要存明文。这一点在Demo阶段也建议照做因为存明文密码这个习惯一旦养成后面很难改。6. 建完之后验证、迭代与几个我踩过的坑6.1 建完表先做三件事再写Java代码DDL执行完不要急着打开IDE写实体类。先做三件验证第一SHOW TABLES确认三张表都在第二DESC article看一眼字段类型和默认值是否符合预期特别是DATETIME的默认值和TINYINT的默认值第三手动跑一条带join的查询比如查文章列表带用户名和分类名确认关联字段类型一致、能正常join出结果。SELECT a.id, a.title, u.username, c.name AS category_name FROM article a LEFT JOIN user u ON a.user_id u.id LEFT JOIN category c ON a.category_id c.id WHERE a.is_deleted 0 ORDER BY a.created_at DESC;这条查询能跑通说明表结构、关联字段、软删除标记都没问题后面写Mapper时心里有底。如果join出来是空或者报错问题一定出在字段类型或数据上这时候排查比写完Java代码再排查容易得多。6.2 字段类型不一致导致join失效这个坑我踩过早期做Demo时用户表主键是BIGINT文章表的user_id我随手写成了INT结果join查询时MySQL做了隐式类型转换数据量小的时候能出结果但走不了索引而且某些边界情况下关联会错位。更隐蔽的是如果一边是VARCHAR一边是INTMySQL会把VARCHAR转成INT再比较001和1会被认为是相等的这种隐式转换导致的错误极难排查。所以关联字段的类型必须严格一致这是建表时的硬性检查项。我的做法是建完表后专门核对一遍所有_id字段的类型和被引用表主键类型逐一对齐都是BIGINT就都是BIGINT不能一个BIGINT一个INT。6.3 改表结构时ALTER和重建怎么选Demo做到一半发现字段不够用或者类型不对是常有的事。这时候有两个选择ALTER TABLE改或者drop掉重建。判断标准是数据还要不要。如果表里只有种子数据、随时可以重造那就drop重建改DDL文件重新执行干净利落还能保证DDL文件和实际库结构一致。如果表里已经有手动造的、不好复现的测试数据那就用ALTER。ALTER的常见操作加字段ALTER TABLE article ADD COLUMN summary VARCHAR(300) DEFAULT NULL;改类型ALTER TABLE article MODIFY COLUMN title VARCHAR(300) NOT NULL;加索引ALTER TABLE article ADD INDEX idx_user_id (user_id);。改类型时要注意如果原字段有数据且新类型范围更小可能截断Demo阶段数据少影响不大但养成先备份或先确认数据量的习惯。我个人的偏好是Demo阶段DDL文件就是唯一事实来源每次改结构都改DDL文件然后重建库这样任何时候把DDL文件发给别人对方执行一遍就能得到一模一样的库。这个习惯让环境不一致这类问题在Demo阶段就绝迹了。6.4 把DDL纳入版本管理比想象中重要最后说一个容易被忽略的点DDL文件要跟着代码一起进版本库。很多人建完库就把SQL随手扔在桌面或者客户端的历史记录里过几天换个环境就找不到了只能凭记忆重建字段名、类型、默认值全靠回忆重建出来的库和原来对不上代码跑起来各种报错。正确做法是在项目里建一个db目录放schema.sql建库建表和data.sql种子数据两个文件和代码一起提交。这样任何时候clone下来执行这两个文件就能得到完整的库。更进一步如果用的是Spring Boot可以把这两个文件放到src/main/resources下配合相关配置让应用启动时自动执行Demo的开箱即跑体验会好很多。这个习惯的成本几乎为零但省下的排查时间非常可观。

JavaEE小Demo数据库设计实战：从建库建表到DDL版本管理

相关推荐

Linux日志分析与应急响应：可信度分层、时间线重建与证据固化

营销技能实战拆解：从用户洞察到活动策划的完整方法论

SAP零售AI解决方案：智能补货与动态定价实战解析

更多资讯

拓数派云原生数据库与AI驱动的数据资产化实践

Loop Engineering：构建可审计、可复现的AI编码闭环

AI算法在自然科学中的应用与实践指南

用AI补齐接口设计与异常处理：FastAPI项目实战

AI辅助接口设计与异常处理：小项目质量提升实战

无人机与AI技术在马铃薯病害检测中的应用与数据集解析

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？