Java+SSM+Django老年公寓信息管理系统设计与实现

聊一个最近重新整理过的题目：Java+SSM+Django老年公寓信息管理系统。这几个词摆在一起，懂的都懂，这就是那种典型的“毕业设计/课程设计全栈项目”，但别因为它常见就小看它。养老社区、智能化养老这些概念这两年确实火，可绝大多数养老公寓的管理方式还停留在纸质台账和单人Excel表格，老人档案、床位状态、护理记录、费用流水各记各的，月底一对账就抓瞎。这个项目要做的，就是把老年公寓日常运营里的信息孤岛打通，做成一套能真正跑起来的管理软件：所有角色在同一个系统里登记信息、处理业务、汇总数据，整个过程有权限控制、有操作留痕、有报表统计。从实用的角度说，它既能当毕设题目交差，也能给刚入行的人当企业级应用练手素材，源码、论文文档、调试文档和讲解视频都齐了，照着复现一遍，收获会比单纯背面试题大得多。

1. 项目整体设计与需求拆解

很多同学拿到这种题目第一反应是“不就是增删改查吗”，这话对一半，但只说中了皮毛。老年公寓信息管理系统难点不在单张表的CRUD，而在于业务角色多、状态流转多、数据关联多。先把这些理清楚，后面写代码才有方向。

1.1 业务角色与核心痛点分析

系统里需要区分的角色大致有这几类：

• 系统管理员：管账号、管权限、管基础数据，什么都能看。
• 前台/接待人员：办理老人入住登记、安排房间床位、登记访客。
• 护理人员：查看自己负责的老人列表，填写每日护理记录、健康状态。
• 财务/收费人员：生成每月费用账单，登记缴费情况，查看欠费名单。
• 家属（通常是只读账号）：查看老人基本信息、护理记录、费用明细。

从角色就能倒推痛点：以前用Excel管的时候，老人入住后房间床位是否被占用、护理员今天有没有按时巡房、某位老人的费用有没有漏缴，全都靠人肉记忆。项目要把这些状态变成“数据流转”：入住时房间状态自动变为已占用，护理记录实时累计，费用模块根据床位费和护理项目自动生成账单，家属账号一登录就能看到老人近况。

1.2 功能模块划分与数据流向

我把系统按业务线拆成几个大模块，这也是论文里写“系统功能结构图”的主要依据：

• 老人信息管理：基本信息录入、档案详情、照片上传、健康档案、入住状态变更。
• 公寓房间管理：楼栋/楼层/房间/床位四级关联，支持根据状态查询空床位。
• 护理管理：护理任务排班、护理记录登记、异常情况标记。
• 餐饮管理：可选，记录老人饮食习惯和每日供餐情况。
• 费用管理：月度账单自动生成、收费登记、欠费提醒、费用统计。
• 访客管理：来访登记、离开登记、访客历史查询。
• 系统管理：用户管理、角色权限、修改密码、操作日志。

数据流向是一条主线：老人在前台登记入住，关联房间；护理员每天提交护理记录；财务月底跑一遍费用结算；管理端看统计报表。所有模块都围绕“老人”这个核心实体展开，所以数据库设计时一定要以老人表为轴心。

1.3 为什么这个项目要用两套后端技术栈

很多第一次看到“Java+SSM+Django”这个组合的人会问：是不是写错了？一边是Java的SSM（Spring + SpringMVC + MyBatis），一边是Python的Django，这两套东西平时很少出现在同一个单体项目里。

这里要解释一下，这种组合在实训类项目里很常见。它不是让你非得把两套框架揉进一个进程，而是做成双子系统集成：

• 核心业务端用Java SSM，负责老人档案、房间、护理、收费这些事务性强的模块，因为SSM在传统管理信息系统里非常成熟，权限、事务、接口都好控制。
• 数据统计端用Django，负责读取数据库做聚合分析，比如入住率报表、年龄分布、费用趋势、床位利用分析，再用图表方式展示。Python在数据处理上确实比Java写起来更顺手。

两者通过MySQL共享数据，Django侧纯读取，不写业务表，避免并发锁冲突。管理端页面里放一个“统计报表”菜单，点击跳转到Django服务的端口。对外演示时，可以说这个项目同时展示了Java企业级开发能力和Python数据分析能力，这也是题目设计成组合技术栈的原因之一。

提示：如果你只是自己练手，不想折腾两套服务，完全可以只用SSM完成全部功能。但按这个题目的要求，Django报表模块是加分项，答辩时也能多聊几分钟。

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

管理系统的底盘是数据库。这项目表不算多，但关系要理得清楚，尤其是一对多、多对一的关系不能乱。下面列出最核心的五张表，照着建就能跑通整个业务主线。

2.1 老人表与房间表：一对多的核心关系

老人表是系统主表，字段设计时要把“档案信息”和“入住信息”合并在一起，避免过度拆表：

CREATE TABLE elder ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL COMMENT '姓名', gender TINYINT COMMENT '性别 1男 2女', birth_date DATE COMMENT '出生日期', id_card VARCHAR(18) COMMENT '身份证号', phone VARCHAR(20) COMMENT '老人/家属联系电话', emergency_contact VARCHAR(50) COMMENT '紧急联系人', emergency_phone VARCHAR(20) COMMENT '紧急联系电话', room_id INT COMMENT '关联房间ID', bed_no VARCHAR(10) COMMENT '床号', checkin_date DATE COMMENT '入住日期', health_status VARCHAR(100) COMMENT '健康状态描述', status TINYINT DEFAULT 1 COMMENT '1在住 0退住', photo VARCHAR(255) COMMENT '照片路径', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

房间表要体现出“公寓”的层级：楼栋、楼层、房号。每个房间有固定床位数量，通过已住人数判断是否已满：

CREATE TABLE room ( id INT PRIMARY KEY AUTO_INCREMENT, building_no VARCHAR(10) COMMENT '楼栋号', floor_no INT COMMENT '楼层', room_no VARCHAR(10) COMMENT '房间号', room_type VARCHAR(20) COMMENT '单人间/双人间/多人间', bed_count INT DEFAULT 1 COMMENT '床位数', occupied_count INT DEFAULT 0 COMMENT '已住人数', status TINYINT DEFAULT 0 COMMENT '0空闲 1部分占用 2已满', remark VARCHAR(200) );

入住登记时，系统要先查目标房间的occupied_count是否小于bed_count，然后更新占用状态。这个逻辑虽然简单，但是容易漏，做的时候一定要放在事务里，连同老人表插入一起提交，避免房间满了还能继续塞人。

2.2 员工表与护理记录表：业务发生的凭证

护理人员归员工表管理：

CREATE TABLE employee ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, position VARCHAR(30) COMMENT '岗位：护理员/护士/保洁/厨师', phone VARCHAR(20), work_no VARCHAR(20) COMMENT '工号', status TINYINT DEFAULT 1 COMMENT '1在职 0离职' );

护理记录是每天产生数据最多的表，需要冗余关联老人姓名和护理员姓名，避免后期统计每次都去联表：

CREATE TABLE care_record ( id INT PRIMARY KEY AUTO_INCREMENT, elder_id INT NOT NULL, elder_name VARCHAR(50), employee_id INT NOT NULL, employee_name VARCHAR(50), care_type VARCHAR(30) COMMENT '生活照料/健康监测/用药提醒/康复训练', care_content VARCHAR(500) COMMENT '护理内容', care_date DATE, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, remark VARCHAR(200) );

很多新手会忽略冗余字段的用法，总觉得保持范式精简就是好的。实际操作里，报表查询和列表展示如果动不动就JOIN三张表，慢不说，代码也啰嗦。对于这种课程设计级别的项目，适度冗余是最划算的优化。

2.3 费用表与用户权限表

费用表是财务模块的底气：

CREATE TABLE fee_record ( id INT PRIMARY KEY AUTO_INCREMENT, elder_id INT NOT NULL, fee_type VARCHAR(30) COMMENT '床位费/护理费/餐饮费/医疗费/其他', amount DECIMAL(10,2) NOT NULL, month VARCHAR(7) COMMENT '账期，如2025-02', status TINYINT DEFAULT 0 COMMENT '0未缴 1已缴', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, pay_time DATETIME );

用户权限表最简单的做法是一个user表加一个role字段，多个角色就用逗号分隔，或者拆一张role表。个人建议用最简单的角色字段就够了，没必要引入复杂的权限框架，这个规模的项目用拦截器判断角色名称足够了：

CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) UNIQUE NOT NULL, password VARCHAR(100) NOT NULL COMMENT 'MD5或BCrypt加密', real_name VARCHAR(50), role VARCHAR(20) COMMENT 'admin/employee/finance/family', status TINYINT DEFAULT 1 );

密码加密建议至少用MD5加盐，能上BCrypt更好，别明文存。面试时会问，论文里也能写一句“采用加密存储防止拖库泄露”。

3. 后端框架整合与核心功能实现

这一部分直接进入实操，先说SSM侧的关键配置和代码，再说Django侧报表模块的接入。

3.1 SSM框架整合的四个关键点

SSM整合网上配置模板很多，但容易踩坑的其实是下面四个点：

第一，Maven依赖版本必须锁死。Spring、SpringMVC、MyBatis三个框架各自版本一定要兼容，我建议Spring用5.x，MyBatis用3.5.x，MyBatis-Spring用2.0.x。别一把梭全用最新版，新版本配合老教程很容易出现类找不到、方法签名不匹配这种莫名其妙的问题。

第二，MyBatis的Mapper XML文件要放到resources目录下，并配置路径。很多人把Mapper写在java目录里，结果编译的时候根本没进target/classes，运行直接报“Invalid bound statement”。spring配置里这样写：

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath*:mapper/*.xml"/> </bean>

第三，SpringMVC的扫描范围要收敛。千万别把@Service、@Repository所在的包让SpringMVC的上下文重复扫描，只让它扫Controller包就够了，否则事务注解会失效，因为Spring容器和SpringMVC容器各管一套Bean。

第四，事务一定要配。至少要在Service层加@Transactional，尤其是入住登记、费用生成这种多表操作。没配事务，插入老人表成功但房间更新失败，数据就脏了。

3.2 核心功能一：入住登记事务流

入住登记是最能体现“事务”价值的场景。Service层的代码大致这样：

@Service @Transactional public class ElderServiceImpl implements ElderService { @Resource private ElderMapper elderMapper; @Resource private RoomMapper roomMapper; public void checkIn(Elder elder, Integer roomId) { Room room = roomMapper.selectById(roomId); if (room.getOccupiedCount() >= room.getBedCount()) { throw new RuntimeException("该房间已满，无法安排入住"); } room.setOccupiedCount(room.getOccupiedCount() + 1); if (room.getOccupiedCount().equals(room.getBedCount())) { room.setStatus(2); // 已满 } else { room.setStatus(1); // 部分占用 } roomMapper.updateById(room); elder.setRoomId(roomId); elderMapper.insert(elder); } }

注意判断逻辑：先查房间，后改房间，再插老人表。若插入老人表失败，整个方法抛异常，事务回滚，房间占用不会残留，这就是事务的作用。另外建议每次操作前后打印一下参数日志，调试时能少很多时间。

3.3 核心功能二：费用账单自动生成

费用模块如果纯手工录入，财务能烦死。合理的做法是写一个定时生成任务的入口，比如在管理端“生成账单”按钮，按月份和老人状态批量生成：

List<Elder> elderList = elderMapper.selectAllCheckedIn(); for (Elder elder : elderList) { FeeRecord record = new FeeRecord(); record.setElderId(elder.getId()); record.setMonth(month); record.setFeeType("床位费"); record.setAmount(calcBedFee(elder.getRoomId())); record.setStatus(0); feeMapper.insert(record); // 同时生成护理费、餐饮费等其他账单 }

实际项目里，费用计算规则可能按护理等级区分，比如自理老人和半失能老人护理费不同，所以老人表里建议加一个care_level字段，计算时根据等级取单价。

3.4 Django统计报表模块的实现方式

Django模块是整个项目的统计学担当，但它不需要包含全部业务页面，只做四件事：读取MySQL数据、按维度聚合、渲染图表、支持导出Excel。

Django侧配置MySQL连接，建议把系统设置为只读。可以直接用Django的Model读库，也可以干脆不建Model，直接用pymysql查SQL。我倾向于后者，因为报表SQL大多是多表聚合，用Model反而绕：

import pymysql from django.http import JsonResponse def room_report(request): conn = pymysql.connect( host='127.0.0.1', user='root', password='123456', database='elder_apartment', charset='utf8mb4' ) cursor = conn.cursor() sql = """ SELECT SUM(CASE WHEN occupied_count > 0 THEN 1 ELSE 0 END) AS used_rooms, SUM(bed_count) AS total_beds, SUM(occupied_count) AS total_elders FROM room """ cursor.execute(sql) row = cursor.fetchone() total_rooms = ... # 计算入住率 return JsonResponse({'room_used': row[0], 'total_beds': row[1]})

Django页面这里推荐用简单的方式渲染图表，比如后端计算好数据后传到模板，配合ECharts或Chart.js画图，不用引入太重的东西。前端菜单点击跳到http://127.0.0.1:8000/report/，跨端口访问时记得在SSM侧页面加个target="_blank"或使用iframe，同时处理CORS，否则浏览器控制台会报跨域错误。

3.5 前后端接口约定与数据交互

SSM项目如果是传统方式，页面直接用JSP + JSTL渲染，Controller返回ModelAndView或字符串视图。如果想用前后端分离方式，Controller统一返回JSON，前端用Vue或原生JS的fetch取数。

我实际更推荐半分离：页面框架用JSP或Thymeleaf，局部刷新用Ajax。这样既保留服务端渲染首页面的简单性，又让交互顺手。Controller可以设计成：

@Controller @RequestMapping("/elder") public class ElderController { @GetMapping("/list") public String list(Model model) { model.addAttribute("list", elderService.findAll()); return "elder/list"; } @PostMapping("/save") @ResponseBody public Map<String, Object> save(@RequestBody Elder elder) { int result = elderService.insertOrUpdate(elder); return Map.of("code", result > 0 ? 0 : 1, "msg", result > 0 ? "保存成功" : "保存失败"); } }

前后端交互的数据格式要统一：成功返回{code:0, data:xx, msg:"成功"}，失败返回{code:1, msg:"原因"}，这样做的好处是前端不管做表单提交还是列表加载，都只用一套错误处理逻辑。

4. 系统部署与调试实录

项目代码写完只是第一步，能把环境跑起来、把演示流程走顺，才算真正完工。这一章记录我在部署调试过程中遇到的实际问题，其中不少坑能直接省你几天时间。

4.1 开发环境清单与版本推荐

我先列一套经过了验证的环境组合，照着装基本不会翻车：

• JDK 1.8（别用太高版本，SSM老框架对高版本兼容容易出问题）
• Maven 3.6+
• Tomcat 8.5/9.0
• MySQL 5.7或8.0（MySQL8注意认证插件问题，Django连接时要用pymysql并加配置）
• Python 3.8+
• Django 3.2（LTS版本稳定，太久旧的版本对新系统兼容性差）
• IDE推荐IDEA，社区版就够用

4.2 从源码包到本地跑通的完整步骤

拿到源码之后，按这个顺序操作成功率最高：

1. 建库：执行源码里的elder_apartment.sql脚本生成所有表和初始数据。
2. 改配置：SSM项目的jdbc.properties里改数据库账号密码，Django项目里改DATABASES配置。
3. 启动SSM服务：用Maven的tomcat7:run插件或用IDEA配置Tomcat启动。项目路径名要确认，访问地址应该是http://localhost:8080/{项目名}/。
4. 启动Django服务：在项目根目录执行python manage.py runserver 8000。
5. 联调：先单独登录SSM系统，再单独访问Django报表接口，最后从SSM页面跳转Django报表看是否正常。
6. 初始化账号：从SQL初始化数据里拿管理员账号密码登录，通常默认是admin/admin123。

注意：启动顺序没有硬性要求，但建议先MySQL，再SSM，最后Django，这样出错时好定位是哪一层没起好。

4.3 高频异常排错表

下面这些问题是每次帮人看项目时出现频率最高的，直接做成速查表：

异常现象	原因	解决办法
启动Tomcat立刻失败，端口占用	Tomcat默认8080被占用	改Tomcat端口，或在任务管理器结束占用进程
数据库中文乱码	连接URL没指定编码	JDBC URL加characterEncoding=utf8，MySQL表结构设为utf8mb4
“Invalid bound statement”	Mapper XML没打进classpath	检查resources目录结构和Mapper扫描路径
Django连接MySQL报caching_sha2_password	MySQL8默认认证插件与pymysql不兼容	给MySQL用户指定mysql_native_password，或用新版PyMySQL
页面跨域请求被拦截	前后端端口不同	后端加CORS过滤器，配置允许跨域
日志出现ClassNotFoundException	Maven依赖下载不完整	删除本地仓库相关目录，重新mvn clean install
表单提交后返回404	URL映射大小写/后缀不对	检查Controller的@RequestMapping和页面form action路径

这几类问题解决后，系统基本就稳定了。再往后就是业务演示要提前准备“数据剧本”，比如提前录入几位有代表性的老人，用不同护理等级、不同缴费状态做演示，比临时造数据强很多。

5. 避坑心得与答辩/交付经验

项目做到最后，很多人会忽略一个关键认知：毕设或项目交付不只是写码，更重要的是“你能讲清楚为什么这么做”。这里把这些经验单独列出来分享。

5.1 写论文/文档时的三个加分结构

配套文档如果只是贴代码和截屏，答辩老师很容易觉得单薄。建议在论文逻辑里强化这三个部分：

第一，需求分析要从现状痛点推导。别说“客户需要系统”，要说“当前人工管理模式在床位统计、护理记录追溯和费用结算上存在滞后，本系统通过……解决这些问题”。有对比才有说服力。

第二，数据库设计要交代冗余和索引策略。比如为什么在护理记录表里冗余老人姓名和护理员姓名，为什么要给elder_id、month等字段加索引。这些细节是区分“背代码”和“真懂系统”的分水岭。

第三，Django报表部分要写成亮点章节。说明Python技术栈是如何作为独立分析子系统集成的，数据是如何从核心业务库抽取指标的，展示一张入住率趋势图并解读业务含义。

5.2 项目演示时的“流程剧本”

我强烈建议准备一份演示脚本，按时间线走，不要东点一下西点一下。我的习惯顺序是：

1. 先用管理员登录，展示系统管理模块的权限控制。
2. 演示入住登记流程：建老人档案、分配到房间，然后立刻去房间列表看占用状态变化。
3. 演示护理员提交护理记录，去老人详情页看到记录刷新。
4. 进入费用管理，点击生成当月账单，看到未缴列表。
5. 切到Django报表页，展示入住率、年龄分布、费用统计三个图表。
6. 最后展示退住或换房流程，体现房间状态联动更新。

这个流程把“数据流转逻辑”完整串起来了，比零散展示更能让人信服。

5.3 后续扩展：从完成项目到产品化

如果这个项目之后想继续做，我建议两个方向：

一是加移动端支持。做一个微信小程序或H5页面，让家属可以随时看老人的护理记录和费用信息。技术栈可以继续用Django做小程序后端接口，或者给SSM加一个移动端API模块。

二是接物联网硬件。房间里的烟雾报警器、老人随身手环如果能对接进来，就是真正的“智能化养老”了。毕设答辩时提一两句“后续可对接硬件设备”，显得视野宽，但别写在已完成功能里。

我个人在实际调试中的体会是，这类管理系统最大的难点从来不是某个框架的语法，而是数据一致性和流程完整性。房间占用、费用生成、权限控制这些环节，只要有一个地方没考虑周全，演示时就会当场翻车。建议做完一个功能就立刻从用户角度过一遍全流程，别只看着页面能用就以为大功告成。项目源码和文档能帮你快速起步，但真正值钱的经验，永远是在一遍遍调试和跑通流程的过程中攒下来的。