农贸市场摊位管理系统：SSM框架下的数据库设计与业务实现

计算机毕设选题年年都在变，但农贸市场摊位管理这类系统，放在今天依然有它的独特价值。不是因为它有多新的技术，而是它把SSM框架、关系型数据库设计、权限模型、业务状态机这些Java后端核心知识点，全部揉进了一个真实可落地的场景里。如果你正在准备毕设，或者想找一个能讲清楚“业务逻辑”的练手项目，这篇东西值得你花十分钟看完。我会从需求拆解、表结构设计、核心功能实现到高频踩坑，把整个系统怎么从零搭起来讲透。

1. 项目整体设计与技术选型思路

1.1 为什么是农贸市场摊位管理，而不是图书管理

很多同学选毕设题目喜欢选图书管理、学生选课这类老掉牙的系统。不是说不行，而是这类题目在答辩时很难讲出亮点，因为评委老师已经看过太多一模一样的CRUD了。农贸市场摊位管理系统不一样，它天然带几个别的系统没有的特点。

第一，它有多角色协作。系统里至少有三类人：市场管理员（招商、收费、巡查）、财务人员（租金核算）、摊主（查看自己的摊位信息和缴费记录）。多角色意味着要有完善的权限控制，而权限控制恰好是毕设答辩时高频被问的点。

第二，它有明确的业务状态流转。一个摊位从“空闲”到“已出租”再到“合同到期退租”，这中间的每一次状态变化都牵扯到合同、费用、台账。这种状态变化用一张status字段硬扛是扛不住的，它逼你去思考状态机设计、操作记录留痕这些问题。

第三，它有真实的数据关联复杂度。摊位表和合同表是一对多，合同表和缴费记录表是一对多，用户表又和合同表关联。这种环环相扣的数据关系，才是数据库设计的核心训练场景。

计算机毕设选题年年都在变，但农贸市场摊位管理这类系统，放在今天依然有它的独特价值。不是因为它有多新的技术，而是它把SSM框架、关系型数据库设计、权限模型、业务状态机这些Java后端核心知识点，全部揉进了一个真实可落地的场景里。如果你正在准备毕设，或者想找一个能讲清楚“业务逻辑”的练手项目，这篇东西值得你花十分钟看完。我会从需求拆解、表结构设计、核心功能实现到高频踩坑，把整个系统怎么从零搭起来讲透。

1.2 SSM框架选型背后的事

SSM就是Spring + Spring MVC + MyBatis的组合，放在2025年看确实不算新，但它依然是Java后端入门最稳的组合。

Spring管对象，Spring MVC管接口，MyBatis管数据库。三层各司其职，结构非常清晰，特别适合用来理解Java Web开发的基本模型。如果你直接用Spring Boot，很多东西是被“自动配置”掉的，你反而不知道背后发生了什么。用SSM，你得自己配数据源、自己配事务管理器、自己写MyBatis的Mapper XML，这些过程虽然烦，但每走一步都在加深理解。

我见过不少同学答辩时被问“Spring Boot和SSM的区别”，支支吾吾答不上来。原因就是他们根本没经历过SSM手搭的过程。做过一遍SSM的人，心里是有那张依赖关系图的。

当然，如果用SSM，版本选择要非常小心。Spring用5.x，JDK用1.8，MyBatis用3.5.x，Maven管理依赖。这套组合我实测下来是兼容性最稳的，不要盲目追求新版。

2. 数据库设计与核心表结构拆解

2.1 全景表结构总览

一个摊位管理系统，核心表我认为至少要有六张：用户表、角色表、摊位表、合同表、缴费记录表、公告表。另外建议加一张操作日志表，答辩时有这张表会很有说服力。

数据库用MySQL 5.7或8.0都可以。字符集统一用utf8mb4，别用utf8，否则遇到生僻字或者特殊符号会乱码。排序规则用utf8mb4_general_ci即可。

先看用户表和角色表。用户表（t_user）的核心字段有id、username、password、real_name、phone、role_id、status。密码字段要存MD5或BCrypt加密后的值，绝对不允许明文。角色表（t_role）就是id和role_name，比如管理员、财务、摊主。用户表和角色表通过role_id关联，一个用户一个角色，简单直接。如果你想让系统显得更正规，可以做成多对多的用户角色关联表，但毕设场景下，一对一角色足够用，还能减少不必要的复杂度。

摊位表（t_stall）是业务核心。字段要包含：stall_no（摊位编号，比如A区01号）、area（所属区域）、category（经营品类，蔬菜、水果、肉类等）、area_size（面积，单位平方米）、monthly_rent（月租金）、status（0空闲 1已出租 2维修中 3已停用）、create_time。注意，area和status这类字段建议用枚举值加数字存储，而不是直接存中文，这样可以避免数据不一致的问题。

合同表（t_contract）关联摊位和用户（摊主）。字段包含：contract_no（合同编号，唯一）、stall_id（摊位ID）、user_id（摊主用户ID）、start_date（合同开始日期）、end_date（合同结束日期）、monthly_rent（合同租金）、deposit（押金）、status（0生效中 1已到期 2已终止）、create_time。合同表是连接摊位和用户的桥梁，也是缴费记录的业务来源。

缴费记录表（t_payment）记录每一笔租金或押金的收支。字段包含：contract_id（关联合同）、payment_type（0租金 1押金 2其他费用）、amount（金额）、payment_time（缴费时间）、operator_id（经办人）、remark（备注）。这张表是财务视角的核心表，做统计报表的时候全靠它。

公告表和日志表相比之下简单很多。公告表（t_notice）就是title、content、publish_time、publisher_id。日志表（t_operation_log）就是user_id、operation、operation_time、detail。日志表建议用AOP切面去做自动记录，后面我会详细说。

2.2 为什么一定要有合同生命周期这个概念

很多同学做摊位管理，会直接把“摊位状态”和“是否出租”画等号。这个想法在数据量小的时候问题不大，但一旦业务复杂起来，就会出大问题。

举个例子：某摊位合同到期了，但摊主还没来得及搬走，这个时候摊位状态是“空闲”还是“已出租”？如果把这两个概念混在一起，你没法回答这个问题。所以必须引入合同生命周期的概念。

合同状态有两种关键流转路径。正常到期路径：生效中 -> 已到期，此时摊位可以重新招租。提前终止路径：生效中 -> 已终止，此时需要记录终止原因。每次合同状态变化，都要同步更新摊位表的状态。

这种“主数据（摊位）状态”和“业务单据（合同）状态”分离的设计，是很多真实业务系统的通用做法。你把它讲清楚，答辩时评委就知道你是真的思考过业务，而不是光会写增删改查。

2.3 索引设计上的几个细节

表结构设计完了，索引不能乱建。我见过不少毕设代码，全部查询都是全表扫描，数据量小的时候没感觉，答辩演示的时候如果数据造得多了，页面会卡得厉害。

核心查询路径有这几条：根据用户名查用户（登录），根据摊位编号查摊位，根据合同ID查缴费记录，根据时间范围查缴费流水。所以至少要在这些字段上建索引：t_user.username（唯一索引）、t_stall.stall_no（唯一索引）、t_contract.contract_no（唯一索引）、t_payment.contract_id（普通索引）、t_payment.payment_time（普通索引）。

唯一索引还有个好处，就是在代码层面做兜底，防止重复数据。比如你不可能允许两个用户有相同的用户名，这条约束光靠代码判断是不够的，数据库唯一索引才是底线。

3. 核心功能实现与业务代码落地

3.1 项目工程结构怎么组织

我见过太多毕设代码把Controller、Service、Mapper全部塞在几个包下面，一眼望去全是controller、service、mapper这种包名。这个结构本身没错，但在做业务型系统时，更推荐按业务模块分包。

按模块分包的结构大概是这样的：

code复制com.market
├── common          // 通用工具、返回结果封装、异常处理
├── system          // 系统管理：用户、角色、菜单、日志
├── stall           // 摊位管理
├── contract        // 合同管理
├── payment         // 缴费管理
└── notice          // 公告管理

每个模块包下面再分controller、service、mapper、entity这些子包。这样做的好处是，业务相关的代码在物理上聚集在一起，你改合同模块的代码不需要去别的地方翻来翻去，维护成本低很多。答辩的时候讲项目结构，这种按业务拆包的方式也更像一个“正经系统”该有的模样。

3.2 统一返回结果与异常处理

这部分看起来不起眼，但实际是代码质量的试金石。很多同学的接口返回什么都有：有的返回Map，有的返回JSONObject，有的干脆返回一个字符串。看起来功能正常，但前端对接的时候就知道有多痛苦了。

我建议定义一个统一的返回类，比如Result<T>，里面有三个字段：code（200成功，500失败）、message（提示信息）、data（业务数据）。所有Controller的返回值都封装成这个对象，前端只要做一次统一处理就行。

异常处理用@ControllerAdvice + @ExceptionHandler做全局拦截。这样Service层抛出业务异常时，不需要每个Controller都写try-catch，全局异常处理器会自动捕获并转成统一的Result结构返回。这样做有两个好处：代码干净，不会出现大量重复的try-catch；错误信息可控，不会把系统内部的异常堆栈直接暴露给前端。

3.3 登录拦截与权限校验

登录拦截可以说是每个系统必备的功能。用Spring MVC的HandlerInterceptor实现登录拦截是最经典的做法。

思路很简单。写一个LoginInterceptor，实现HandlerInterceptor接口，在preHandle方法里判断当前请求的session中是否有登录用户信息。如果没有，直接返回错误信息，终止请求；如果有，放行。

接着要考虑一个问题：哪些接口需要登录，哪些接口不需要？比如登录接口本身肯定不能拦截，不然永远登录不了。有两种处理方式：一种是在拦截器里用excludePathPatterns排除登录接口；另一种是给接口加上自定义注解，比如@LoginRequired，然后在拦截器里判断是否有这个注解。

第二种方式更灵活。因为有些接口可能既要登录，又要特定角色才能访问，这时候可以在注解上加一个role属性，比如@RequireRole("admin")，在拦截器里做判断。这种基于注解的权限控制，比硬编码判断当前用户角色要优雅得多。

3.4 摊位招租与退租的业务逻辑

这两个操作是整个系统最重要的业务，也是答辩时最容易出彩的地方。

招租流程是这样：前端提交一个招租请求，包含摊位ID、摊主用户ID、租期、月租金、押金等参数。后端要做的事情依次是：

1. 校验摊主用户是否存在且角色为“摊主”。
2. 校验摊位状态是否为“空闲”，如果不是直接抛异常。
3. 创建一个合同记录，状态为“生效中”。
4. 修改该摊位状态为“已出租”。
5. 记录一条操作日志。

注意第2步和第4步，两步修改了不同的表，必须放在同一个事务里。如果在创建合同成功之后、修改摊位状态之前发生异常，合同和摊位数据就不一致了。这个事务是必须加的，不加必出线上事故，答辩时评委也一定会问。

退租流程就反过来。校验合同状态是“生效中”，然后更新合同状态为“已到期”，再修改摊位状态为“空闲”。这里有一个细节：退租时可能还有未结清的费用，退租操作要考虑是否生成一条应收记录。加上这个逻辑，系统就显得有商业头脑了。

我写一下这个事务控制的伪代码，大家感受一下：

java复制@Transactional(rollbackFor = Exception.class)
public void leaseStall(LeaseRequest request) {
    // 1. 校验摊位状态
    Stall stall = stallMapper.selectById(request.getStallId());
    if (stall == null || stall.getStatus() != 0) {
        throw new BusinessException("摊位不存在或已被占用");
    }
    // 2. 创建合同
    Contract contract = new Contract();
    contract.setContractNo(generateContractNo());
    contract.setStallId(request.getStallId());
    contract.setUserId(request.getUserId());
    contract.setStartDate(request.getStartDate());
    contract.setEndDate(request.getEndDate());
    contract.setStatus(0);
    contractMapper.insert(contract);
    // 3. 修改摊位状态
    stall.setStatus(1);
    stallMapper.updateById(stall);
}

@Transactional注解加在Service层的方法上，rollbackFor = Exception.class表示所有异常都会触发回滚。这个写法是标准操作。

3.5 费用到期自动提醒的设计

这是一个加分项。系统可以提供一个“即将到期”的合同列表，比如30天内到期的合同自动标记为“待续租”。实现方式是在合同查询接口里加一个时间条件的筛选。

查询即将到期合同的SQL大致是这样：

sql复制SELECT * FROM t_contract 
WHERE status = 0 
AND end_date BETWEEN NOW() AND DATE_ADD(NOW(), INTERVAL 30 DAY)

把这个查询做成一个独立的功能页面，合同快到期时，管理员可以提前联系摊主续租或准备重新招租。不需要做太复杂的定时任务，一个查询接口就够了。但有了这个功能，答辩时你就可以说“系统支持合同预警”，说服力比干巴巴的增删改查强太多。

4. 实操过程中的高频问题与排查经验

4.1 SSM环境搭建的坑

SSM项目最大的坑就是版本兼容问题。我见过太多同学卡在项目启动这一步，报各种奇怪的错误。

第一个典型问题是java.lang.NoClassDefFoundError，这种多半是依赖冲突或者依赖缺失。解决办法是把Maven依赖树打出来看一遍，mvn dependency:tree，看看有没有重复的、版本冲突的jar包，排除掉即可。

第二个典型问题是Spring版本和JDK版本不匹配。例如用Spring 6.x却配了JDK 8，启动直接报错。我的建议是SSM组合固定下来：JDK 8 + Spring 5.3.x + Tomcat 8.5/9.0 + Maven 3.6+。这套组合非常成熟，坑最少。

第三个典型问题是ClassNotFoundException: org.springframework.web.servlet.DispatcherServlet。这个多半是Maven的war包插件配置漏了依赖，或者项目没打包成war发布到Tomcat。用IDEA开发时，检查一下Artifacts配置是否把lib目录加了进去。

4.2 MyBatis Mapper XML的常见错误

Mapper XML文件写错是高频问题。最常见的两种：一是resultType和resultMap混淆。resultType可以直接写实体类的全限定名，适合字段名和列名一致的情况。如果数据库列名和实体类属性名不一致（比如stall_no对应stallNo），就要用resultMap做映射。

二是#{}和${}混用。#{}是预处理占位符，会生成?，可以防止SQL注入，查单值用这个。${}是直接拼接SQL字符串，有SQL注入风险，只有在动态表名、动态排序字段这类场景才用。如果有个字段需要模糊查询，正确写法是：

xml复制<select id="selectByKeyword" resultType="com.market.entity.Stall">
    SELECT * FROM t_stall
    WHERE stall_no LIKE CONCAT('%', #{keyword}, '%')
</select>

有的同学爱写'%${keyword}%'，前端传什么就拼什么，这就是把SQL注入的漏洞直接送给了攻击者。这个点评委特别爱问，一定要能讲清楚。

4.3 数据库中文乱码问题排查

中文乱码的根源就一句话：客户端字符集和数据库字符集不一致。

排查思路是逐层检查。先看数据库本身的字符集，SHOW CREATE DATABASE；再看表的字符集；接着看连接字符串是否带了characterEncoding=utf8；最后看IDEA或命令行工具的编码设置。

我强烈建议在JDBC连接字符串里显式加上characterEncoding=utf8，比如：

properties复制jdbc:mysql://localhost:3306/market?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

serverTimezone必须加，否则MySQL 8.0会报时区相关的异常。这个配置项直接决定了你存进去的中文会不会变成问号。

4.4 Lombok的坑与替代方案

很多同学为了少写getter、setter，会在项目里引入Lombok。但Lombok在JDK版本和IDE兼容性上偶尔会出问题。最典型的现象是：代码在IDEA里没有报错，但是用Maven打包的时候报一个非常奇怪的错，you aren't using a compiler supported by lombok。

解决方式有几种。一种是升级Lombok版本到1.18.30以上，这个版本对JDK 17+的支持比较完善。但如果你用的是JDK 8，Lombok 1.16.x到1.18.x其实都能用。

另外一种更稳妥的方案是：毕设项目干脆不用Lombok，直接在实体类上写getter和setter。看着是烦了点，但能少一个大坑。如果你不想手写，可以在IDEA里用快捷键自动生成，或者在实体类上装一个Lombok插件然后保证插件版本匹配。

4.5 分页查询的实现选择

分页是管理系统里逃不掉的功能。我之前遇到过一个情况：数据量几千条，但是列表页加载越来越慢。排查后发现是LIMIT offset, size这个写法在数据量大了以后会有性能问题，offset越大，查询越慢。

毕设场景下，我推荐用PageHelper这个分页插件，它支持物理分页，使用起来很简单：

java复制PageHelper.startPage(pageNum, pageSize);
List<Stall> list = stallMapper.selectAll();
PageInfo<Stall> pageInfo = new PageInfo<>(list);

调用startPage之后，紧跟其后的第一条查询SQL会自动拼接LIMIT语句，查完再自动清空。这个插件很好用，但是有一个注意点：startPage和查询操作之间不能插入其他SQL操作，否则分页会失效，或者影响别的查询。

如果不想用插件，也可以自己写分页逻辑：先查总条数，再查当前页数据，手动拼装PageResult对象。代码多一点，但思路更透明，答辩时也能讲得头头是道。

5. 答疑环节与避坑经验速查

5.1 答辩时最容易被问的问题清单

我把这几年积累的答辩高频问题整理成一张速查表，帮助大家在准备阶段有一个方向。

这些问题如果能答得清楚，答辩基本稳了。

5.2 数据造数与演示动线建议

答辩演示最怕的就是现场卡壳，或者数据太少看不出效果。我建议提前造好一套完整的业务数据：20个摊位、8个摊主、6份生效合同、2份到期合同、30条缴费记录，这些数据要能串成一条完整的故事线。

演示的动线可以这样设计：先登录管理端，看到首页统计数据（摊位总数、已租数量、本月租金收入）；然后进入摊位管理，点开一个“空闲”的摊位，演示招租操作；接着去合同管理，看到刚生成的合同，状态是“生效中”；再回到摊位列表，确认摊位状态变成了“已出租”。这样一整条链路走下来，评委能非常直观地看到系统的关联性和完整性。

造数时注意，不要直接在数据库里insert，要用系统本身的注册、招租、缴费功能造数。这么做还有一个好处：你的日志表里会产生大量真实操作记录，展示日志管理功能时也顺手了。

5.3 一些外包项目里才能学到的经验

最后分享两个我认为非常重要的实战经验。

第一个关于金额字段的存储类型。所有涉及金额的字段，务必用DECIMAL(10,2)，不要用FLOAT或DOUBLE。浮点数在计算机内部的存储方式决定了它并不精确，金额一旦算错，就会引起很大的纠纷。DECIMAL是精确保存，适合货币场景。

第二个关于软删除。摊位和合同这类保存着历史业务数据的数据表，不要直接物理删除。建议加一个deleted字段，0表示正常，1表示已删除。查询时统一过滤已删除的记录。这样做的好处是：即使合同被误删，也能从数据库里找回。真正的商业系统，几乎不会轻易物理删数据。

6. 写在最后的一点心得

回到文章开头说的，为什么农贸市场摊位管理系统值得做？因为它不是那种不痛不痒的CRUD，它把数据库关联、事务控制、权限拦截、状态流转这些Java后端最核心的能力，全部串联在了一个大家都能理解的生活场景里。答辩时你可以讲业务逻辑，可以画E-R图，可以聊字段设计，可以谈异常处理，这些都是实打实的加分项。

我自己做这个项目的时候，最有成就感的一刻不是所有接口调通，而是用系统的招租功能，把一笔租金从签订合同到生成缴费记录完整跑完，然后能在缴费统计里看到这个月的收入汇总。那一刻我才真正理解，什么叫“数据在系统里流动起来”。你也一定会有同样的感受。把这个感觉记住，然后去把系统做扎实，比焦虑选题重要一万倍。