SpringBoot实战：油田土地档案管理系统设计与实现

1. 油田土地档案系统到底在做一件什么事

接手这个题目的时候，我第一反应是：这不就是一个普通的CRUD管理系统吗？无非是SpringBoot加个前端框架，配上MySQL做个增删改查，套上权限管理，一个标准的"管理系统"毕业设计或者企业内部项目就出来了。

但真正往深了想一步，事情没那么简单。油田土地档案这四个字，拆开来看各有各的门道。"油田"意味着土地分布范围广、位置偏远、横跨多个行政区域；"土地"意味着业务涉及权属、坐标、面积、地类、使用年限这些非常专业的字段；"档案"意味着系统管理的不是一条条简单的数据记录，而是一整套完整的、带有法律效力的历史材料——包括政府批文、征地协议、土地证扫描件、权属变更文件、补偿记录等。

所以我理解，这个系统本质上要解决的是三个层面的问题：

• 档案数字化：把油田企业历史上积累的纸质土地档案（有些可能是几十年前的）转化为结构化数据和非结构化文件，统一存储、统一检索。
• 权属动态跟踪：一块地从划拨到征用，从临时用地到永久用地，中间可能经历多次变更。系统要能记录每次变更的来龙去脉，形成完整的生命周期链条。
• 多维度统计分析：管理层需要随时知道全油田范围内有多少宗地、总面积多大、哪些地即将到期、哪些地存在权属争议，这是土地管理决策的基础数据支撑。

从这个角度回头看，这个项目虽然顶着"基于SpringBoot"的技术标签，但真正的难点不在技术框架本身，而在于如何用技术手段把土地档案这个复杂业务模型合理抽象出来。SpringBoot只是工具，业务建模和系统架构设计才是核心。

如果你准备照着这个题目做下去，或者你所在的单位正好也有类似的档案管理需求，这篇文章会把整个系统的设计思路、模块划分、技术选型、踩坑经历，一条一条掰开讲清楚。我尽量按实际做项目的路径来讲，而不是按教科书目录来讲。

2. 业务建模先行：先把土地档案的"最小信息单元"定义清楚

做管理系统最容易犯的错误是一上来就建表。表面上看起来效率很高，但通常做到一半就会发现表结构设计不合理，有的是字段冗余，有的是关键信息漏掉了，有的是业务状态变化之后原表结构根本存不下，不得不推倒重来。

我在设计这个系统的数据模型之前，先花了不少时间梳理油田土地档案的业务对象。梳理完之后，整个系统的核心实体其实就那么几类。

2.1 土地档案主表：一条档案记录到底包含哪些字段

先说最核心的档案主表。每一宗土地都应该对应一条唯一的档案主记录。我用到的核心字段大致可以分为五组，每一组都是实际业务中必须用到的：

• 基本标识信息：档案编号（系统唯一）、土地坐落位置、所属油田二级单位、地块面积（精确到0.01平方米）、地类用途（工业用地、办公用地、道路用地、管线用地等）、取得方式（划拨、出让、租赁、授权经营等）。
• 权属信息：土地使用权人、土地证号、发证机关、发证日期、使用权终止日期。这组字段特别重要，因为油田的土地很多是划拨用地，权属关系复杂，同一个地块可能同时存在与地方村集体、政府或其他企业的交叉权属关系。
• 空间位置信息：宗地坐标（可以是宗地图上的拐点坐标序列）、所在行政区划（省、市、县区、乡镇）、是否位于矿区矿权范围内。油田土地管理有个特点，地块经常分布在野外，传统的门牌号地址根本不存在，只能用"区块名称+井号+坐标"这种方式来定位。
• 状态信息：当前使用状态（正常使用、闲置、待处置、权属争议、已退还、已转出）、数据状态（草稿、已归档、已作废）。状态字段一定不能省，否则后续做统计分析和流程流转的时候会非常痛苦。
• 附件关联信息：附件数量、附件总大小，以及和附件表关联的外键关系。

字段类型上也有小讲究。面积建议用DECIMAL(14,2)，不要用FLOAT，否则涉及面积汇总求和、分摊计算的时候会出现浮点误差。有效期开始日期和结束日期用DATE类型，不要用VARCHAR，否则后续做到期提醒的时候SQL查询条件会非常别扭。坐标字段如果只存一个点的中心坐标，VARCHAR(255)就够；如果要存完整拐点序列，建议单独建一个坐标子表，每条记录存一个拐点，按序号排列，方便后续对接GIS系统。

2.2 附件表：文件存储的目录结构设计和命名规范

土地档案最大的特点就是附件多。一份完整的征地档案，可能包含政府批复文件、勘测定界报告、补偿协议、村民签字确认表、现场照片、公示照片、扫描存档的图纸，零零总总加起来几十个文件是常有的事。所以附件表的设计不能敷衍。

我的设计是独立的land_attachment表，核心字段包括附件ID、档案ID（外键）、附件名称、附件类型（批复/协议/图纸/照片/其他）、文件存储路径、文件大小、文件MD5值、上传人、上传时间。

附件文件的物理存储我推荐按"业务目录+日期+随机文件名"分层组织，形式类似这样：

text复制/storage/land-archives/
├── 2025-01/
│   ├── 15/
│   │   ├── 36df7e8c2f7a4b2f9e6bce4d1f0a3a2e_批复.pdf
│   │   └── a1f44b22f9f248e59e5c7c9cc6f98d41_宗地图.png
├── 2025-02/
│   ├── 03/
│   │   └── c8b9d2c61eb14d7f9b5e9f6df3f69f95_勘测定界.pdf

关键点：**存在磁盘上的文件名必须是随机生成的UUID或MD5值，不能直接使用原始文件名。**原始文件名要放在数据库的attachment_name字段里。这样做有三个好处：一是避免中文文件名和特殊字符在Linux系统下引发编码问题；二是避免同一个文件多次上传产生覆盖；三是层级目录按月划分，单目录下的文件数量可控，也方便后续做离线备份。

2.3 权属变更记录表：为什么要单独拆一张表出来

土地权属变更是土地档案管理里最复杂的业务场景。一块地不是拿到手就永远不变的。比如：A地块最初是临时用地，使用期三年，到期后转为永久划拨；B地块的一部分因为规划调整被政府收回，剩余的继续使用；C地块和相邻油田发生了边界重合，需要重新确权。

如果只把最新的权属状态更新到主表里，历史信息就彻底丢失了。将来如果遇到法律纠纷，需要调取某一历史时点的权属状态，就完全无从查证。所以权属变更必须单独建表，且每次变更必须新增一条记录，绝不更新旧记录。

变更记录表的核心字段是：变更ID、档案ID（外键）、原权属人、现权属人、变更类型（使用权变更/面积调整/用途变更/延期/收回/争议处理）、变更前要点（JSON或文本）、变更后要点（JSON或文本）、审批文号、变更日期、经办人、备注。

查询某宗地的完整权属沿革时，只需要一条SQL，按变更日期倒序拉出来，就能清晰展示这块地从初始状态到当前状态的完整时间线。这个能力在应对审计、司法纠纷和上级检查时非常有用。

2.4 字典表和码表：避免硬编码的最后一道防线

土地管理业务里有很多枚举值的字段，如地类用途、取得方式、使用状态、档案类型、附件类型等。如果直接在Java代码里写死这些枚举值，后续业务部门提出"加一种用途类型"的需求时，就不得不改代码、重新打包、重新部署。

我的做法是为每一类枚举值建字典表。比如sys_dict表，字段包括字典类型、字典键、字典值、排序号、是否启用。前端下拉框选项动态从接口读取，后端校验时从缓存读取。这样业务部门提出新增类型时，只需要在管理界面加一条字典记录，重启都不用。

还有一个容易被忽略的字段是"所属二级单位"。油田企业通常是集团-油田分公司-采油厂/作业区多层架构，而且随着油公司改革，组织机构调整非常频繁。所以这个字段也建议走组织架构表，不要直接存字符串。

3. 系统架构和技术选型：为什么这套组合最适合

技术选型的部分，网上一搜一大把关于SpringBoot怎么用的教程，这里不多重复SpringBoot的Hello World，重点是讲清楚在油田土地档案管理这个场景下，为什么是这套技术组合最合理。

3.1 后端框架：SpringBoot 2.7.x，不要盲目追新

SpringBoot版本的选择是第一个需要注意的点。我看到很多初学者一上来就直接用最新版的SpringBoot 3.x，甚至是4.0的某个快照版本。但在实际项目中，尤其是企业管理系统这种场景，我更推荐SpringBoot 2.7.x。

理由很实际：

• JDK兼容性：SpringBoot 2.7.x基于Java 8 / 11开发，而很多企业内网服务器装的还是JDK 8。SpringBoot 3.x要求JDK 17起步，如果服务器环境不满足，上线那一步就直接卡壳了。
• 生态兼容性：截止到现在，mybatis-generator、PageHelper、druid这些国内Java后端常用的三方库，很多的对SpringBoot 3.x的支持还在完善中，遇到问题网上解决的参考资料也相对少。而2.7.x的方案已经被验证了无数次，踩坑资料极其丰富。
• 版本迁移成本：SpringBoot 2.7到3.x之间的核心变化包括javax命名空间变更为jakarta，很多老代码在3.x下是不能直接编译的。如果这个项目是从已有代码改造而来，升级成本不容小视。

我推荐的使用组合是：SpringBoot 2.7.18 + MyBatis-Plus 3.5.x + MySQL 8.0 + Redis（可选） + Sa-Token或Spring Security（二选一）。

MyBatis-Plus是MyBatis的增强工具，代码生成器可以直接根据数据库表结构生成实体类、Mapper、Service、Controller一套代码，对于这种管理系统来说是实打实的效率工具，能省掉大量重复的CRUD代码。权限控制方面，如果项目工期紧且不需要过于细粒度的权限模型，Sa-Token上手更快；如果甲方明确要求基于RBAC的完整权限体系且未来要扩展复杂权限逻辑，直接用Spring Security更稳妥。

3.2 前端方案：能跑、好维护、能交付的优先

这个题目在绝大多数情况下不需要一个重前端项目。油田土地档案管理系统的使用场景是办公室内部的PC端，用户量通常不会超过几百人，核心诉求是操作效率和数据准确性，不是炫酷的交互效果。

所以我建议的搭配是：后端接口服务负责纯API，前端用Vue 3 + Element Plus做单页应用，部署时使用Nginx托管前端静态文件并反向代理后端接口。

如果你时间紧张，连前端SPA都不想写，那至少要把后端接口的边界划分清楚。我见过不少这类项目，后端代码质量不错，但Controller层直接返回了视图模板，前后端逻辑耦合在一起，后续想扩展一个移动端或者做接口对接时非常痛苦。所以哪怕前端再简陋，也建议走前后端分离路线。

3.3 非结构化文件的存储方案：FastDFS在单体系统中并不合适

网上一搜"文件存储"，很多人第一反应是FastDFS或者MinIO。但在SpringBoot单体应用里我建议慎用FastDFS——部署成本高、架构复杂，还要额外维护tracker和storage节点，对于这种档案系统来说完全是高射炮打蚊子。

在数据量没有达到PB级之前，最务实的方案是直接用服务器本地磁盘加Nginx静态映射。文件上传时写入指定的上传目录，文件名规则前面提到过，再用Nginx把/storage/路径映射为静态资源访问。将来数据量起来了，或者需要做高可用，再把本地存储平滑迁移到MinIO或云存储，后端代码只需要改一个FileStorageService接口的实现类即可。

数据库里只需要存文件的相对路径，前端拿到路径拼上Nginx的访问地址就能直接预览和下载。这样做既简单又够用，也是我做这类系统的一贯思路。

4. 核心功能模块的落地实现

架构定下来之后，就要开始逐块实现功能了。这个系统的功能模块大致可以分成六大块：档案管理、权属变更、检索查询、到期预警、统计分析、系统管理。下面挑几个关键点讲实现细节。

4.1 档案录入：事务边界和附件关联是重点

档案录入最核心的逻辑是"一条主记录加上N条附件记录必须同时保存成功"。实现上一定要用@Transactional事务注解包裹整个保存过程，确保主表插入和附件表批量插入要么全成功，要么全失败。

我在这儿踩过一个教训：最开始实现时，附件是单个上传的，前端每次选择完文件就立刻发起上传请求，服务端返回文件存储路径，前端保存到临时列表。等用户点"保存档案"时，再把这些附件路径和档案主记录一起提交到后端。这个方案看似合理，但存在一个问题——如果用户上传了文件但最终没有保存档案，这些文件就成了"孤儿文件"，永远不会被引用，还要另外跑一个定时任务去清理。

后来我改成了更稳妥的方案：

前端选择文件之后先不传服务器，只是本地预览，等用户点保存时，把档案主数据连同附件列表（包含原始文件名和文件二进制内容）一次性提交到后端，后端在一个事务里完成主表插入、文件落盘、附件表插入。文件落盘操作和数据库写入在同一个事务里，虽然理论上存在全部回滚但磁盘文件无法自动回滚的问题，但实际配合定时清理任务完全够用。

4.2 多条件组合检索：LIKE查询和全文检索的边界划分

土地档案的检索需求很常见：档案编号查一条；按土地证号查；按单位查；按状态查；按用地类型查。这种场景用MyBatis-Plus的LambdaQueryWrapper动态拼接条件就能搞定，不需要上搜索引擎。

但有一个容易忽视的需求是全文检索。用户可能只记得批复文件里的某个文号片段，或者某份征地协议里的几个关键词，就想搜出整条档案。如果档案描述和备注没有落到数据库字段，光靠SQL的LIKE '%关键词%'是搜不到的，因为文件内容存在磁盘上，数据库里只有路径。

处理方案有两种：

• 简单方案：把每份档案的关键词抽取出来存到数据库的full_text字段里，录入时人工填关键词，检索时SQL匹配这个字段。
• 进阶方案：引入Elasticsearch做全文检索，上传时用Apache Tika或PDFBox解析PDF、Word、扫描件文字（配合Tesseract OCR），把提取到的文本全文索引进ES，查询走ES。

如果项目工期有限，第一种方案完全够用。如果希望系统具备"现代感"，考虑第二种方案并配好ES的IK中文分词器。这个决策要提前和项目干系人对齐，因为全文检索的实现工作量差异很大。

我个人的建议是：基础的多条件组合检索用SQL，全文检索用Elasticsearch，两者不冲突。SQL检索负责精确、结构化、结果集小；ES检索负责模糊、全文、跨文件内容。两者通过档案ID进行关联。

4.3 到期预警：一条SQL搞定但业务逻辑不能少

土地档案中有大量的"使用权终止日期"，到期前是否及时办理续期是土地管理合规性的重要环节。到期预警功能实现起来不复杂，但业务规则要先梳理清楚：

• 提前90天预警；
• 提前30天高亮显示；
• 已过期未处理标红置顶。

实现上，实体类加一个@TableField(exist = false)的瞬态字段dayDiff，SQL查询时用DATEDIFF(end_date, CURDATE())计算差值，即可在列表页拿到每个地块的到期天数。再用一个定时任务（Spring的@Scheduled）每天凌晨扫描一次，把即将到期的档案生成待办任务推送给相关单位。

这个功能最花时间的不是SQL和定时任务，而是预警对象的确认——谁应该收到预警？档案所属单位的土地管理员？还是财务资产科？还是主管领导？这需要跟业务部门确认，不要自己拍脑袋。

4.4 统计报表：分组聚合和导出Excel的实践

管理层需要看的统计维度无非是：地类用途分布、取得方式分布、各单位土地面积排行榜、到期土地清单、年度增减变化趋势。这些统计在MySQL侧用GROUP BY配合SUM/COUNT就能完成。

真正的坑在导出Excel。方案有三个：

• Apache POI的原生API——灵活但代码量大，合并单元格、样式设置都很繁琐；
• EasyExcel（阿里开源的那种）——推荐，代码简洁，按注解Mapping实体类，支持大数据量分批写；
• 前端导出（JS库如SheetJS）——简单场景可行，但数据量大时容易卡在浏览器端，且列宽、数字格式化能力弱。

我用EasyExcel导出时有个小经验：导出任务如果数据量超过几万行，接口等待时间会明显变长，前端容易报超时。更稳的做法是异步导出——用户点导出，后端立即返回"导出任务已创建"，真正的文件生成放到线程池里执行，完成后将下载链接更新到任务列表里。前端轮询任务状态，就绪后引导用户点击下载。

4.5 权限管理：不要每个接口手动写鉴权

权限设计我建议按RBAC模型来做：用户-角色-菜单/操作权限三层结构。具体实现上用SpringBoot拦截器或AOP统一处理，核心思路如下：

java复制@Component
public class AuthInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 1. 从请求头中解析token（Sa-Token/自研JWT）
        // 2. 根据当前用户ID查询其角色对应的权限标识集合
        // 3. 检查当前请求路径或方法注解标识是否在权限集合中
        // 4. 校验不通过时返回401/403统一JSON响应
        return true;
    }
}

做权限管理时有一个约定俗成的原则：前端隐藏按钮只是体验优化，后端接口必须做校验。比如"档案作废"这个操作，特定角色才能调用对应接口，如果只在前端把按钮隐藏，懂行的人直接调接口就能绕过限制，所以后端权限校验必不可少。

4.6 操作日志：审计合规的隐形需求

土地档案涉及大量权属信息和法律文件，操作留痕是刚需，尤其和审计挂钩。系统里几类关键操作必须记录：登录/登出、档案新增/修改/删除、权属变更、导出文件、审批通过/驳回。

实现方式比较简单：Controller层加一个自定义注解@Log("作废档案")，用AOP切面拦截注解标识的方法，记录操作人、操作时间、操作类型、操作内容JSON、请求IP、执行状态。异步写日志，避免影响业务接口的响应时间。

5. 部署上线阶段的实战记录

系统功能写得差不多了，真正上线部署的时候才是各种坑集中爆发的时候。我挑几个印象最深刻的记录一下，希望能帮后来者少走弯路。

5.1 JDK版本与SpringBoot版本的匹配问题

这是我看了大量相关讨论亲自踩过的坑。开发环境是JDK 8，SpringBoot 2.7.18，测试环境一切正常。但有一次我在一台只有JDK 17的服务器上直接启动SpringBoot 2.7.x的jar包，应用是可以起来的，但逻辑层出现了诡异的java.lang.reflect.InaccessibleObjectException，排查一段时间才发现是JDK强封装模块导致MyBatis-Plus反射操作失败。后来规规矩矩在服务器上装了JDK 8并把JAVA_HOME指过去，问题才彻底解决。

所以如果你用SpringBoot 2.7.x，部署环境的JDK建议直接用8或11，别在17上硬刚。如果项目决定用SpringBoot 3.x，那就老老实实JDK 17以上，Java代码里也要注意避免使用被移除的API，比如javax.annotation.PostConstruct要改成jakarta.annotation.PostConstruct这类。

5.2 文件上传大小限制

系统上线后收到的第一个客诉就是"附件上传失败"。查看日志发现报错MaxUploadSizeExceededException，SpringBoot要求通过spring.servlet.multipart.max-file-size和max-request-size配置项设置上传限制。默认只有1MB，连一份扫描件都传不上去。

我的配置是：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 100MB
      max-request-size: 500MB

同时别忘了Nginx层也要同步调整，client_max_body_size 100m;。如果前端是Vue/Axios上传，还要注意请求超时时间，太大文件的传输时间不能卡在超时阈值上。

5.3 大数据量下的分页性能问题

土地档案的条数在几千到几万条这个范围时，MyBatis-Plus的分页基本没问题。但如果附件表独立出来，且一张档案对应几十个附件，关联查询时用嵌套子查询还是LEFT JOIN，性能差异会非常明显。

我当时的做法是查询列表时先只查主表字段，附件数量用子查询COUNT统计，避免一次性加载所有附件记录到内存。如下：

xml复制<select id="selectArchivePage" resultType="com.example.vo.ArchiveVO">
    SELECT a.*,
           (SELECT COUNT(*) FROM land_attachment att WHERE att.archive_id = a.id) AS attachment_count
    FROM land_archive a
    <where>
        <if test="query.keyword != null and query.keyword != ''">
            AND (a.archive_no LIKE CONCAT('%', #{query.keyword}, '%')
                 OR a.land_cert_no LIKE CONCAT('%', #{query.keyword}, '%')
                 OR a.location LIKE CONCAT('%', #{query.keyword}, '%'))
        </if>
    </where>
    ORDER BY a.create_time DESC
</select>

分页用MyBatis-Plus的Page对象即可，IPage<ArchiveVO> page = new Page<>(pageNum, pageSize);，配合selectPage方法自动生成LIMIT语句。

5.4 服务器的数据库编码踩坑

MySQL安装时如果默认字符集不是utf8mb4，中文和特殊字符（比如地名中的生僻字）入库就会变成乱码。连接串里必须明确指定编码：

text复制jdbc:mysql://localhost:3306/land_archive?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai

同时数据库表级别也要显式设置：

sql复制CREATE DATABASE land_archive DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

这个坑一般不显眼，但一旦出现，全表的中文数据都会乱掉，回滚成本很高，建议在初始化SQL脚本阶段就固定下来。

6. 从"能用"到"好用"的几个经验思考

系统做完、上线、跑起来之后，并不意味着项目就结束了。档案管理系统这类项目的生命力在于数据沉淀和持续演进，所以有几件事值得在项目收尾阶段做掉。

6.1 数据迁入是最大的工作量，入口阶段要建模

很多项目本身开发周期就两三个月，真正耗时最多的是历史数据的整理和导入。油田企业这么多年积攒的土地档案，很多还散落在纸质文件、Excel表格、甚至老旧的单机版系统里。数据迁移的方案要提前设计，包括：Excel模板的标准化、纸质档案的扫描方案、批量导入的校验规则、重复数据的清洗策略。

我建议给系统预留一个"批量导入"的入口，用EasyExcel解析上传的Excel文件，逐行校验后写入正式表，同时生成导入报告（成功行数、失败原因）。让业务部门自己先做一轮数据清洗，技术侧负责提供工具和兜底。

6.2 对接GIS是档案系统绕不开的下一站

土地档案天然和空间位置相关，越往后走，用户一定会提"能不能在图上直接看地块位置"的需求。到那个时候，后端需要输出GeoJSON格式的坐标数据，前端接入OpenLayers或Leaflet即可渲染。数据库层面建议增加一个geo_json字段或独立的坐标表，把宗地拐点坐标提前整理好，否则真到对接GIS的时候，数据缺失会让项目卡壳很长时间。

6.3 不要把系统做成一个孤岛

有价值的系统应该尽量融入企业的整体信息化生态。至少要考虑两件事：

• 统一身份认证：如果企业内部有统一的单点登录平台，需提前了解对接协议，避免上线后二次改造。
• 数据同步：与财务资产系统、生产运行系统之间的土地数据同步关系要梳理清楚，明确哪个系统是数据源头，哪个系统是消费方。避免多个系统维护同一份数据互相矛盾。

7. 最后的一些开发建议

整个项目做下来，有些经验和教训是通用的，不管你是做毕业设计还是接企业的实际项目，应该都用得上。

第一，原型比文档更能统一认知。动手写代码之前，先用原型工具把页面结构和核心流程画出来，一定要和业务方一起过一遍。土地档案管理的业务方往往是年龄偏大的管理人员，你跟他们讲"数据模型""接口设计"没有意义，但他们能非常清楚地告诉你"这个列表里我应该能看到哪几列""这个字段应该放在基本信息里还是权属信息里"。原型过掉之后，再动手编码，返工率会低很多。

第二，从管理角度考虑数据完整性校验。土地档案里有很多关键字段，比如土地证号、使用权终止日期，这些字段缺失会导致后续统计和预警不准。录入时的校验规则要结合实际——不是每个字段都必填，但关键字段必须给足约束。比如"已归档"状态的档案，必须有档案编号、土地证号和面积，否则拒绝归档。

第三，日志和异常处理是做管理系统的下限。我在评审别人代码的时候见过太多不打印日志、直接把异常吞掉的写法。一旦系统出了线上问题，没有任何日志可查，只能靠猜。我的习惯是：Controller层用全局异常处理器统一捕获业务异常，返回给前端友好提示；Service层记录WARN甚至ERROR级别的日志，带上核心参数和堆栈；定时任务里必须加日志，否则凌晨跑了什么、成不成功，完全无从得知。

第四，数据库字段注释是给未来的自己留的路。土地档案表我建了几十张表，如果当时偷懒不写COMMENT，到后来想排查某个字段的业务含义，只能去翻代码或者问写代码的人。所以强烈建议建表SQL里每个字段都加上注释，这是一本万利的投入。

第五，项目的演示数据未必越全越好。给业务方做系统演示的时候，数据库里放什么样的测试数据很有讲究。要放贴合实际业务的数据，比如真实的村名、地块编号、证号格式，这样使用者才觉得"这系统是懂我的"。如果随便造一条"测试地块123"，演示效果会大打折扣。我从一开始就让业务部门提供了一批脱敏后的真实数据，演示时几乎不用额外准备。

按照上述思路把这个系统搭起来、跑起来，你会得到一个结构清晰、业务贴切、可上线可交付的完整项目。技术上没有惊天动地的创新，技术选型也走的是成熟稳定路线，但正因为业务模型考虑得够细、权限设计够稳、数据完整性约束到位，系统才能真正在油