高校數字化編外人員管理系統設計

胡易

摘要：在當今信息技術迅猛發展的時代背景下，文章緊密結合高校編外人員的人事管理工作，深入分析了高校自主開發編外人員管理系統的可行性。文章以RuoYi-Vue（一種基于SpringBoot和Vue的前后端分離的Java快速開發框架）為項目腳手架，從編外人員的管理需求分析、數據庫架構設計以及功能實現等關鍵環節出發，詳細展示了一種經濟高效的編外人員管理系統開發路徑。希望通過這一系統，能夠輔助高校編外人員管理實現信息化、智能化的轉型。

關鍵詞：編外人員管理；信息化；程序設計

中圖分類號：TP311 文獻標識碼：A

文章編號：1009-3044（2024）13-0051-04 開放科學（資源服務）標識碼（OSID） ：

1 高校編外人事系統現狀

人事工作作為高校行政管理工作中的重要一環，涉及大量的統計、匯總工作。傳統的工作模式依賴人工，存在效率不高和數據容易出錯的問題。隨著信息時代的到來，高校人事工作也轉換了新模式，引入了相應的人事系統。在提升辦事效率的同時，數據的準確性也得到了保障。但是早期的人事系統往往只關注編內人員信息的維護和統計，不涉及編外人員部分[1]。對于高校而言，尤其是高職院校，對現有系統的采購和升級往往伴隨著巨額的經濟投入。即便面臨部分功能缺失的問題，短期內也難以實現新功能的增補。科技進步的步伐雖快，卻常因資金等限制在高校中難以得到有效應用，這一現象無疑令人遺憾。這也導致高校中的編外人員往往未能被納入信息化系統的覆蓋范圍，從而在信息管理的進程中處于邊緣地位。而編外人員信息化管理又是高校人員身份信息化數據治理的大勢所趨[2]。所以如何找到經濟可行的方案將編外人員進行信息化管理，已成為當前亟待解決的問題。

2 自主設計開發系統的可能性

在傳統的人事系統設計中，B/S架構的WEB開發模式被廣泛采用。用戶無須安裝專門的客戶端，僅通過瀏覽器即可進行業務操作，因此設計開發工作主要集中在服務器端。過去，大多數系統基于Microsoft公司的ASP（Active Server Pages） 技術[3] 或Sun 公司的J2EE（Java 2 Platform Enterprise Edition） 架構[4]進行開發，但這些技術存在開發周期長、需要眾多開發人員的缺點。對于普通高校，特別是高職院校而言，具備相關專業知識的教師數量和精力都難以支撐如此大規模的系統設計開發。從技術發展的角度看，上述兩種技術已逐漸顯得過時。近年來，隨著Java平臺上Spring Boot這類快速應用開發框架的興起，服務器端程序開發的效率得到了顯著提升。國內開發者更是基于服務端Spring Boot框架，結合前端技術如Vue或React，整合出了諸如RuoYi、JEECG BOOT等完整的快速開發腳手架，進一步降低了B/S架構的WEB開發難度。這使得即使在預算有限的情況下，具備相關專業知識的教師也能通過短暫學習，針對學校自身需求開發出一套符合業務要求的編外人員信息系統。對學校而言，采用這種方案有兩大優點。一是與原來的ASP技術相比，Spring Boot開發的項目不再局限于Mi?crosoft Windows平臺，可以運行在開源的Linux服務器上，從而降低了服務器成本。二是諸如RuoYi、JEECG BOOT等均為開源項目（其中RuoYi遵循MIT 協議，JEECG BOOT遵循Apache-2.0協議），基于此進行開發無須擔心授權費用等問題。

3 編外人員管理系統技術選型

在技術的選型上，依托開源項目進行開發，在人力資源投入和資金成本方面均展現出顯著優勢。但不同的開源協議具有不同的條款和限制，從后續開發的限制程度、搭配數據庫是否開源等角度考慮，此處選擇了更為合適的基于MIT協議的RuoYi-Vue（一個基于SpringBoot+Vue 前后端分離的Java 快速開發框架），后文簡稱RuoYi-Vue。RuoYi-Vue對應的前端框架為Vue和Element UI，后端則基于Spring Boot。服務器上，可以選擇開源的MySQL社區版數據庫作為數據源，并選用開源的Redis（Key-Value 數據庫）來配合MySQL進行數據緩存。采用這一技術體系組合，是基于以下幾個方面的優勢考慮。首先，在成本效益方面，開源軟件顯著降低了購買商業軟件許可證的成本。其次，在靈活性方面，它允許根據不斷變化的業務需求進行個性化定制，而不必受制于商業軟件提供商的產品規劃。在維護性方面，眾多開源項目享有活躍的社區支持，確保了軟件能夠定期更新，及時修復缺陷并優化性能，從而避免了商業軟件供應商撤出市場后可能出現的維護真空問題。最后，在安全性和透明度方面，開源軟件的源代碼公開性有助于更迅速地識別和修復安全漏洞。

4 編外人員管理系統需求分析

編外人員管理系統作為人事系統的一個特殊分支（或子集），涵蓋了人事管理系統所必備的四大功能：用戶管理、角色管理、機構（部門）管理以及日志記錄。同時，針對編外人員的特性，系統還應關注以下幾個功能：1） 人員基本信息展示：詳細展示姓名、身份證號、性別、政治面貌、學歷、職稱與技能等級、用工方式、是否為退休返聘、本單位工作年限等關鍵個人信息。2） 崗位信息管理：記錄崗位分類、所在部門以及從事的具體崗位。3） 合同管理功能：管理合同的簽訂情況，包括歷次合同的起始與結束日期，以便于隨時查閱合同執行與續簽情況。4） 收入管理功能：精確記錄基本工資、績效工資等收入信息，為薪酬管理提供清晰的數據支持。5） 條件化查詢與數據導出：系統提供針對上述四個方面的靈活查詢和數據導出功能，以便于快速檢索和分析人員信息，從而提升管理效率。

5 編外人員管理系統功能設計

根據以上需求，系統設計分為兩大模塊：1） 通用管理系統模塊。2） 針對編外人員管理業務的專用模塊（查詢和導出模塊嵌入到編外管理系統專用模塊中），如圖1所示。其中通用管理系統模塊，RuoYi-Vue快速開發平臺中代碼已經實現。

5.1 人員信息功能設計

在提取需求分析中的信息時，除了涵蓋基本的人員信息，如姓名、身份證號、性別、政治面貌、出生日期、民族、籍貫、職稱與技能等級，以及用工方式、是否退休返聘、在本單位的工作年限外，還應將個人對應的崗位信息整合其中，以便于進行綜合展示。因此，設計時應包含展示個人對應的崗位分類、崗位分類下的專項以及具體從事的崗位。同樣地，社保的繳納狀態、公積金的繳納狀態、工資資金來源等與個人緊密相關的信息也應在人員信息中一并展示。對于新建的人員，應賦予其登錄權限，并分配查看和修改自己相關信息的角色權限。基于上述要求，最終數據庫中人員信息表的建表語句如下：

CREATE TABLE `sys_people` （

`people_id` bigint NOT NULL AUTO_INCREMENT COMMENT ′人員ID′，

`user_id` bigint DEFAULT NULL COMMENT ′用戶ID（和登錄用戶對應）′，

`login_name` varchar（30） DEFAULT NULL COMMENT ′登錄名-用于創建賬號的時候使用′，

`dept_id` bigint DEFAULT NULL COMMENT ′部門id′，

`identification_number` varchar（18） CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT ′00′ COMMENT ′身份證號′，

`user_name` varchar（50） CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT ′′COMMENT ′用戶姓名（創建時同步填充到user 昵稱中）′，

`gender` char（1） DEFAULT NULL COMMENT ′用戶性別（0男 1女 2未知）′，

`political_status` varchar（100） CHARACTER SETutf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ′政治面貌′，

`degree` varchar（30） CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ′學歷′，

`birthday` date DEFAULT NULL COMMENT ′ 生日′，

`ethnic` varchar（30） DEFAULT NULL COMMENT ′ 民族′，

`origin` varchar（50） DEFAULT NULL COMMENT ′ 籍貫′，

`title` varchar（30） DEFAULT NULL COMMENT ′職稱或技能等級′，

`hire_method` varchar（50） DEFAULT NULL COMMENT ′用工方式′，

`retired` char（1） CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ′是否退休返聘（Y表示是，N表示否）′，

`position_kind` varchar（30） CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ′崗位分類′，

`position` varchar（30） DEFAULT NULL COMMENT ′崗位分類專項′，

`work_detail` varchar（30） DEFAULT NULL COMMENT ′具體從事崗位′，

`social_security` char（1） DEFAULT NULL COMMENT ′是否繳納社保（Y表示是，N表示否）′，

`housing_provident_fund` char（1） DEFAULT NULL COMMENT ′是否繳納住房公積金（Y表示是，N表示否）′，

`source` varchar（30） DEFAULT NULL COMMENT ′ 資金來源′，

`start_work_time` varchar（255） CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ′參加工作時間′，

`remark` varchar（500） CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ′備注′，

`create_by` varchar（64） CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT ′′COMMENT ′創建者′，

`create_time` datetime DEFAULT NULL COMMENT ′創建時間′，

`update_by` varchar（64） CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT ′′COMMENT ′更新者′，

`update_time` datetime DEFAULT NULL COMMENT ′更新時間′，

`del_flag` char（1） CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT ′0′ COMMENT ′刪除標志（0代表存在 2代表刪除）′，

PRIMARY KEY （`people_id`） USING BTREE

） ENGINE=InnoDB AUTO_INCREMENT=115 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT=′人員信息表′;

其中的login_name字段對應到系統內置用戶信息表（RuoYi-Vue的sys_user表）中的user_name字段，而人員信息的真實姓名user_name字段對應到用戶信息表nick_name字段。這樣設計是為了考慮教師存在重名的情況，但是登錄名user_name不能重復，所以分開設置。而dept_id 表示的部門id 和用戶信息表dept_id意義一樣，這樣方便在新建人員的過程中能夠建立用戶、賦予預置角色。同時，該表并沒有和用戶信息表建立外鍵關聯，主要是為了保持結構的簡化和未來的可擴展性，并且避免了級聯操作帶來的性能問題。表里的del_flag字段用來進行軟刪除，對于刪除人員，為了防止以后要恢復，設置為通過del_flag來標記刪除，而不對數據庫進行真實刪除操作。對應刪除功能的MyBatis的語句為：

通過這樣的表結構設計，在充分利用系統已有的用戶信息的同時，人員信息模塊能相對實現低耦合。

5.2 合同信息功能設計

合同的關注點主要在于簽訂的次數和時段，因此，數據庫設計人員在設計合同表時應當包括以下幾個字段：合同id、合同開始時間、合同結束時間以及合同類型。此外，由于合同與人員之間存在多對一的關系，所以合同表中還應包含人員id字段。為了與上面人員信息設計的思路保持一致，并為了方便數據的恢復，人員合同表依舊使用刪除標志來實現“軟刪除”。因此建表語句如下：

CREATE TABLE `business_contract` （

`contract_id` bigint NOT NULL AUTO_INCREMENT COMMENT ′合同id′，

`people_id` bigint NOT NULL COMMENT ′ 人員id′，

`start_time` date NOT NULL COMMENT ′合同開始時間′，

`end_time` date DEFAULT NULL COMMENT ′合同結束時間′，

`contract_type` char（1） CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ′合同類型′，

`delete_flag` char（1） CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ′刪除標志′，

PRIMARY KEY （`contract_id`）

） ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT=′人員合同表′;

對于合同而言，合同結束時間肯定小于合同開始時間，所以在前端可以加入函數驗證，防止填寫錯誤導致數據問題。驗證函數為：

delete_flag 字段和前面人員信息表的del_flag 字段設計一致，就不贅述了。

5.3 收入信息功能設計

收入功能的設計需要考慮兩個方面：一是每月個人的工資情況，二是每月的收入匯總。而這兩方面依據參考文獻[5]中的工資結構、設置薪級、崗位工資、薪級工資、基礎性績效、獎勵性績效以及它們的合計（作為收入合計）等字段。同時考慮業務上的需求，對收入數據提供鎖定字段salary_lock，實現鎖定功能。在工資發放后可對數據進行鎖定，保證數據不再被修改。人員收入表的建表語句如下：

CREATE TABLE `business_salary` （

`id` bigint NOT NULL AUTO_INCREMENT COMMENT ′薪水id′，

`peopleId` bigint NOT NULL COMMENT ′人員id′，

`level` int NOT NULL COMMENT ′當前薪級′，

`foundational_performance` int NOT NULL COMMENT ′基礎性績效′，

`reward_subsidy` decimal（7， 2） NOT NULL COMMENT ′獎勵性績效′，

`position_salary` int NOT NULL COMMENT ′崗位工資′，

`salary_grade` int NOT NULL COMMENT ′薪級工資′，

`total_salary` decimal（9，2） NOT NULL COMMENT ′ 收入合計′，

`salary_date` date NOT NULL COMMENT ′工資發放日期′，

`salary_lock` int NOT NULL COMMENT ′工資是否鎖定′，

`salary_sumid` int NOT NULL COMMENT ′對應人員匯總表id′，

PRIMARY KEY （`id`）

） ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT=′人員收入表′; 對應的人員收入匯總表建表語句如下：

CREATE TABLE `business_salary_sum` （

`salary_sum_id` bigint NOT NULL AUTO_INCREMENT COMMENT ′收入匯總表id′，

`foundational_performance_sum` int NOT NULL COMMENT ′基礎性績效匯總′，

`reward_subsidy_sum` decimal（7， 2） NOT NULL COMMENT ′獎勵性績效匯總′，

`position_salary_sum` int NOT NULL COMMENT ′ 崗位工資匯總′，

`salary_grade_sum` int NOT NULL COMMENT ′薪級工資匯總′，

`total_salary` decimal（10，2） NOT NULL COMMENT′收入合計匯總′，

`salary_date` date NOT NULL COMMENT ′工資發放日期′，

`salary_lock` int NOT NULL COMMENT ′工資是否鎖定，1表示鎖定，0表示未鎖定′，

PRIMARY KEY （`salary_sum_id`）

） ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT=′人員收入匯總表′;

這樣設計中，針對同一月份的同類型數據，人員收入表中個人數據項之和將直接對應人員收入匯總表中的相應數據值。因為專門設定了鎖定字段，在對數據的修改和刪除時，應該檢驗數據是否為鎖定狀態。如為鎖定，則拒絕修改、刪除。在實現service層代碼中加入工資鎖定狀態的判斷代碼如下：

鑒于人員收入匯總表與人員收入表之間存在數值上的累加關系，對人員收入表的每一次數據增加、刪除或修改操作，都必須相應地同步更新匯總表，以保持數據的一致性和準確性。

6 結束語

隨著計算機技術的不斷進步，如今B/S 架構的WEB開發難度已大為降低，眾多開源項目的涌現進一步提升了開發效率。這使得普通高校，甚至實力相對較弱的高職院校，也能依靠自身設計并開發出一套滿足自身業務需求的編外人員管理系統。本系統的設計旨在滿足基本工作場景需求的同時，提升工作效率，減少統計工作中的錯誤。此外，它還節約了人事部門的人力物力，為推進智慧化校園建設貢獻力量。

參考文獻：

[1] 岳建人. H公立高校編外教職工管理問題及對策研究[D].鄭州：華北水利水電大學，2021.

[2] 葉寧. 高校人員身份信息化數據治理策略研究[J]. 信息記錄材料，2023，24（10）：16-19.

[3] 呂睿光. 高校人事管理系統的設計與實現[D]. 長春：吉林大學，2013.

[4] 張計龍，張成洪，張凱，等. 基于改進MVC的高校人事管理系統[J]. 計算機工程，2004，30（8）：191-194.

[5] 張暢. 地方普通高校機關行政人員績效工資分配改進研究[D]. 昆明：云南大學，2021.

【通聯編輯：代影】

基金項目：2023 年云南體育運動職業技術學院校級科研項目“高校數字化編外人員管理系統設計——以云南體育運動職業技術學院為例”（項目編號：YNTZ2023014）