簡介這是一份面向高校數(shù)據(jù)庫課程設(shè)計(jì)場景的醫(yī)藥信息管理系統(tǒng)完整項(xiàng)目包覆蓋藥品、員工、客戶、供應(yīng)商等基礎(chǔ)信息維護(hù)并實(shí)現(xiàn)進(jìn)貨、庫房、銷售、財(cái)務(wù)統(tǒng)計(jì)四大業(yè)務(wù)模塊適合正在做數(shù)據(jù)庫課設(shè)或畢設(shè)、需要可直接運(yùn)行參考系統(tǒng)的學(xué)生。資源為zip壓縮包共335個文件約4.05MB體積緊湊便于快速部署其中含150個gif演示截圖、54個java源碼文件以及html/js/css前端頁面、sql數(shù)據(jù)庫腳本、Maven配置和項(xiàng)目說明文件目錄結(jié)構(gòu)清晰便于導(dǎo)入IDE后整體跑通。目前已有71人學(xué)習(xí)下載。包內(nèi)完整代碼和界面素材可直接用于理解系統(tǒng)分層與數(shù)據(jù)庫表設(shè)計(jì)也可在此基礎(chǔ)上擴(kuò)展訂單、庫存預(yù)警等功能能有效節(jié)省前后端搭建時間是完成醫(yī)藥管理類課設(shè)的高價值參考資料。1. 數(shù)據(jù)庫課設(shè)醫(yī)藥信息管理系統(tǒng)一張?zhí)幏嚼镉卸嗌贁?shù)據(jù)要管數(shù)據(jù)庫課程設(shè)計(jì)只要題目一帶“醫(yī)藥信息管理系統(tǒng)”很多同學(xué)第一反應(yīng)就是“又是藥品增刪改查”。但真要在答辯時把一張?zhí)幏街v清楚背后其實(shí)是三庫分離的底子藥品基礎(chǔ)數(shù)據(jù)、供應(yīng)商與采購流水、客戶處方與銷售庫存。這個系統(tǒng)最自然的落點(diǎn)是用 MySQL 或 SQL Server 建出符合第三范式的十幾張表再用事務(wù)把“開處方→扣庫存→記流水”這一串動作包起來讓數(shù)據(jù)要么全部生效、要么全部回滾。適合誰做MySQL、SQL Server 這門課剛學(xué)完、想在課設(shè)里同時體現(xiàn)“設(shè)計(jì)能力 代碼落地”的同學(xué)也適合畢業(yè)設(shè)計(jì)想低成本先搭一個能演示的醫(yī)療業(yè)務(wù)底座。讀完這篇你能照著一套可復(fù)現(xiàn)的建表 SQL 和 JavaJDBC調(diào)用方式把數(shù)據(jù)庫課設(shè)從“畫 ER 圖”一路做到“能開機(jī)演示”。2. 先設(shè)計(jì)再建表ER 模型、范式與 8 張核心表課設(shè)答辯時最容易被追問的不是“你怎么寫代碼”而是“為什么這么建表”。所以建表之前必須先把業(yè)務(wù)實(shí)體抽出來再按范式和后續(xù)查詢習(xí)慣去拆表真正落地成 SQL。2.1 從業(yè)務(wù)流程抽實(shí)體藥品、供應(yīng)商、庫存和處方誰先誰后醫(yī)藥信息管理系統(tǒng)最常見的業(yè)務(wù)閉環(huán)是采購入庫 → 庫存管理 → 銷售出庫。圍繞這個閉環(huán)實(shí)體有七八個是正常的少了會被老師說“太簡陋”多了又容易掉進(jìn)過度設(shè)計(jì)。我一般按四條主線去抽藥品主線藥品信息、藥品分類、藥品規(guī)格。采購主線供應(yīng)商、采購訂單、采購明細(xì)、入庫記錄。銷售主線客戶或患者、處方/銷售單、銷售明細(xì)、退款記錄。庫存與財(cái)務(wù)主線庫存表、流水表、盤點(diǎn)記錄。這里最關(guān)鍵的設(shè)計(jì)決策是藥品信息表只放“通用屬性”把價格、批號、效期放到獨(dú)立的表里。很多課設(shè)把藥品表搞成一個大寬表加上drug_name、price、stock、expire_date一大堆——一修改就冗余。更穩(wěn)的做法是拆出drug_stock和drug_batch。批號獨(dú)立成表還有一個實(shí)際好處藥監(jiān)場景下同一藥品多個批號、不同進(jìn)價、不同效期按“一藥一批”做管理才說得通。ER 圖里把這兩個多值字段拆出去天然符合第二范式和第三范式。2.2 三段式建庫建庫、建表、插種子數(shù)據(jù)下面這組 SQL 以 MySQL 8.0 為準(zhǔn)SQL Server 2019 只要把AUTO_INCREMENT換成IDENTITY(1,1)、反引號去掉就能平移過去。先建庫再建核心表最后灌種子數(shù)據(jù)用于演示。-- 建庫字符集用 utf8mb4避免中文和生僻字亂碼 CREATE DATABASE IF NOT EXISTS pharma_sys DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE pharma_sys; -- 1. 藥品分類表樹形結(jié)構(gòu)parent_id 指向自身主鍵 CREATE TABLE drug_category ( id INT AUTO_INCREMENT PRIMARY KEY, parent_id INT DEFAULT 0 COMMENT 父分類 id0 表示頂級, category_name VARCHAR(50) NOT NULL, sort_order INT DEFAULT 0 ); -- 2. 藥品信息表只有“不變”的基礎(chǔ)屬性 CREATE TABLE drug_info ( id INT AUTO_INCREMENT PRIMARY KEY, category_id INT NOT NULL, drug_code VARCHAR(20) NOT NULL UNIQUE COMMENT 藥品編碼作為業(yè)務(wù)唯一鍵, drug_name VARCHAR(100) NOT NULL, spec VARCHAR(50) COMMENT 規(guī)格如 5mg*20片, unit VARCHAR(10) DEFAULT 盒, manufacturer VARCHAR(100), approval_no VARCHAR(30) COMMENT 批準(zhǔn)文號, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 3. 供應(yīng)商表 CREATE TABLE supplier ( id INT AUTO_INCREMENT PRIMARY KEY, supplier_name VARCHAR(100) NOT NULL, contact_person VARCHAR(20), phone VARCHAR(20), address VARCHAR(200) ); -- 4. 藥品庫存表數(shù)量只在這里維護(hù) CREATE TABLE drug_stock ( drug_id INT PRIMARY KEY COMMENT 與 drug_info.id 一一對應(yīng), batch_no VARCHAR(30) COMMENT 批號, expire_date DATE COMMENT 效期, quantity DECIMAL(12,3) DEFAULT 0 COMMENT 庫存數(shù)量支持最小拆零單位, purchase_price DECIMAL(10,3), sale_price DECIMAL(10,2) );字段說明里要特別注意decimal而不是float金額和數(shù)量在課設(shè)里看起來都是小數(shù)但float是近似存儲1.4 變成 1.399999999 的新聞年年有。價格用DECIMAL(10,2)庫存用DECIMAL(12,3)是為了兼容“按克賣”的拆零藥品演示時也能講出理由。drug_code單獨(dú)加唯一索引避免業(yè)務(wù)里拿自增主鍵到處傳——這是給藥品、供應(yīng)商、處方三個模塊共用的“主鍵外露”教訓(xùn)。銷售側(cè)的兩張表單獨(dú)再建因?yàn)樗鼈兂袚?dān)“流水”職責(zé)不適合和基礎(chǔ)表混在一起-- 5. 銷售主表處方/銷售單頭 CREATE TABLE sales_order ( id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(20) NOT NULL UNIQUE COMMENT 單號演示時用時間戳生成, customer_name VARCHAR(50), total_amount DECIMAL(10,2) DEFAULT 0, sale_status TINYINT DEFAULT 0 COMMENT 0 待付款 1 已付款 2 已退款, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 6. 銷售明細(xì)表一個單頭對應(yīng)多行 CREATE TABLE sales_order_item ( id INT AUTO_INCREMENT PRIMARY KEY, order_id INT NOT NULL, drug_id INT NOT NULL, drug_name VARCHAR(100) COMMENT 冗余字段防止藥品改名后歷史單看不清, quantity DECIMAL(10,3) NOT NULL, price DECIMAL(10,2) NOT NULL, amount DECIMAL(10,2) NOT NULL COMMENT quantity * price ); -- 7. 入庫記錄表供應(yīng)商、采購、效期一起落這里 CREATE TABLE stock_in_record ( id INT AUTO_INCREMENT PRIMARY KEY, drug_id INT NOT NULL, supplier_id INT, batch_no VARCHAR(30), quantity DECIMAL(10,3) NOT NULL, purchase_price DECIMAL(10,3), operate_user VARCHAR(20), in_time DATETIME DEFAULT CURRENT_TIMESTAMP );sales_order_item里冗余drug_name看似違反范式實(shí)際上是有意為之歷史銷售單里的藥品名必須“定格”否則藥品改名之后報(bào)表上全是新名字說不清楚當(dāng)時賣的是什么。這個設(shè)計(jì)點(diǎn)答辯時主動講老師會認(rèn)為你理解“范式是為了查詢服務(wù)不是教條”。2.3 外鍵與索引什么時候該設(shè)什么時候不該設(shè)建表之后就是外鍵和索引的選擇題。外鍵在課設(shè)里建議設(shè)因?yàn)閟ales_order_item.order_id、drug_stock.drug_id這類關(guān)系是強(qiáng)約束寫不存在的藥品編碼直接報(bào)錯演示時也能體現(xiàn)“數(shù)據(jù)庫自身在兜底”。但要注意stock_in_record.supplier_id這類弱關(guān)聯(lián)我一般不加外鍵加一個普通索引就可以因?yàn)楣?yīng)商改不修改并不影響入庫流水加了外鍵反而會讓DELETE FROM supplier頻頻失敗。索引是數(shù)據(jù)庫優(yōu)化里最容易講出內(nèi)容的點(diǎn)。sales_order的order_no必須唯一索引sales_order_item的order_id加普通索引stock_in_record的drug_id batch_no加聯(lián)合索引。真正要克制的是不要在每列都加索引醫(yī)藥系統(tǒng)里頻繁查詢的是“按單號查明細(xì)”“按藥品查庫存”“按供應(yīng)商查流水”這三條覆蓋到了就夠用。3. 把增刪改查做“穩(wěn)”事務(wù)、存儲過程與連接池配置表建好只是地基。很多數(shù)據(jù)庫課設(shè)的死穴是業(yè)務(wù)代碼里先查庫存再改庫存結(jié)果兩個窗口同時下單庫存變成了負(fù)數(shù)。所以這一章要解決的核心問題是“并發(fā)和一致怎么在自己手里控制住”落到三個點(diǎn)上事務(wù)邊界、庫存扣減的原子更新、連接池參數(shù)。3.1 并發(fā)扣庫存為什么必須用行鎖而不是先查后改“先查數(shù)量是否夠 → 夠就 UPDATE”是新手最常見的寫法也是高并發(fā)翻車的源頭。兩個會話同時讀到庫存還剩 10各自都判斷“夠”各自減去 1庫存最終變成 9但實(shí)際賣了 2 件。數(shù)據(jù)庫里的行鎖解決的是“寫之間互斥”不是“讀與寫之間互斥”所以靠“先查后改”根本鎖不住。解法是把判斷和扣減合成一條 SQL利用行鎖的原子性-- 扣庫存一次 UPDATE 完成“查詢 校驗(yàn) 修改” UPDATE drug_stock SET quantity quantity - 1 WHERE drug_id 1 AND quantity 1; -- 影響行數(shù) 1扣減成功 -- 影響行數(shù) 0庫存不足回滾整個事務(wù)這條 SQL 在任何隔離級別下都不會超賣quantity 1條件讓多余的扣減直接匹配不到行而 UPDATE 本身會對命中的行加排他鎖。再配合下面的庫存流水表記錄就能做到“賬實(shí)相符”。-- 庫存流水每次增減都記一行作為審計(jì)依據(jù) CREATE TABLE stock_flow ( id INT AUTO_INCREMENT PRIMARY KEY, drug_id INT NOT NULL, change_type TINYINT COMMENT 1 入庫 2 銷售出庫 3 盤點(diǎn)調(diào)整, change_quantity DECIMAL(10,3), before_quantity DECIMAL(10,3), after_quantity DECIMAL(10,3), flow_time DATETIME DEFAULT CURRENT_TIMESTAMP );參數(shù)說明change_type用TINYINT加注釋存數(shù)字不存中文數(shù)據(jù)量上來之后查詢和統(tǒng)計(jì)都方便。before_quantity和after_quantity留雙份快照是為了報(bào)表里直接算出“變化前后”避免再去關(guān)聯(lián)庫存表。血淚經(jīng)驗(yàn)如果庫存流水只記變化量不記前后值年終盤點(diǎn)對賬時基本要重跑一遍全量數(shù)據(jù)才能定位差異。3.2 用存儲過程包住“銷售主表 明細(xì) 庫存”三件事多表寫入的正確姿勢是放在一個事務(wù)里。這里給一個 MySQL 存儲過程的寫法它把三步操作包成單次調(diào)用插入銷售主表、批量插入明細(xì)、逐條扣庫存。任何一步失敗全部回滾。DELIMITER $$ CREATE PROCEDURE sp_create_sales_order( IN p_order_no VARCHAR(20), IN p_customer_name VARCHAR(50), IN p_items JSON -- 明細(xì)以 JSON 數(shù)組傳入 ) BEGIN DECLARE v_order_id INT; DECLARE v_drug_id INT; DECLARE v_qty DECIMAL(10,3); DECLARE v_rows INT DEFAULT 0; DECLARE v_i INT DEFAULT 0; START TRANSACTION; -- 1. 寫銷售主表 INSERT INTO sales_order(order_no, customer_name, sale_status) VALUES(p_order_no, p_customer_name, 1); SET v_order_id LAST_INSERT_ID(); -- 2. 解析 JSON 數(shù)組逐條寫明細(xì)并扣庫存 SET v_rows JSON_LENGTH(p_items); WHILE v_i v_rows DO SET v_drug_id JSON_UNQUOTE(JSON_EXTRACT(p_items, CONCAT($[, v_i, ].drugId))); SET v_qty JSON_UNQUOTE(JSON_EXTRACT(p_items, CONCAT($[, v_i, ].quantity))); INSERT INTO sales_order_item(order_id, drug_id, drug_name, quantity, price, amount) SELECT v_order_id, id, drug_name, v_qty, sale_price, v_qty * sale_price FROM drug_info JOIN drug_stock ON drug_info.id drug_stock.drug_id WHERE drug_info.id v_drug_id; -- 上面 INSERT 影響行數(shù)為 0 說明藥品不存在直接回滾 IF ROW_COUNT() 0 THEN ROLLBACK; SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 藥品不存在或已停售; END IF; -- 原子扣庫存影響行數(shù)為 0 說明庫存不足 UPDATE drug_stock SET quantity quantity - v_qty WHERE drug_id v_drug_id AND quantity v_qty; IF ROW_COUNT() 0 THEN ROLLBACK; SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 庫存不足; END IF; SET v_i v_i 1; END WHILE; -- 3. 更新主表總金額 UPDATE sales_order SET total_amount (SELECT SUM(amount) FROM sales_order_item WHERE order_id v_order_id) WHERE id v_order_id; COMMIT; END$$ DELIMITER ;這段代碼的核心不是 JSON 解析而是事務(wù)邊界的切割。START TRANSACTION之后所有寫操作共享同一個事務(wù)中間任何ROLLBACK都會把已插入的明細(xì)撤干凈。參數(shù)里p_items用 JSON 僅僅是為了演示一個完整調(diào)用鏈如果你課設(shè)的數(shù)據(jù)庫是 SQL Server 2019可以把 JSON 換成臨時表或表值參數(shù)思路完全一致。調(diào)用方Java 的 JDBC只需要CallableStatement注冊這三個參數(shù)p_order_no、p_customer_name、p_items。注意 JSON 字符串里不能用單引號包鍵名MySQL 的 JSON 解析只認(rèn)雙引號這段在聯(lián)調(diào)時經(jīng)常被卡一下。3.3 連接池參數(shù)與 UTF-8Navicat 導(dǎo)出腳本常見的被埋參數(shù)課設(shè)里數(shù)據(jù)庫連接最常出問題的是兩處JDBC URL 忘了加characterEncoding以及連接池線程配得太小導(dǎo)致“假死”。下面是一份實(shí)際可用的druid.properties配置及注釋# Druid 連接池基礎(chǔ)參數(shù) driverClassNamecom.mysql.cj.jdbc.Driver urljdbc:mysql://localhost:3306/pharma_sys?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/ShanghaiuseSSLfalse usernameroot password你的密碼 # 初始連接數(shù) / 最小空閑 / 最大活躍 initialSize5 minIdle5 maxActive20 # 獲取連接的超時時間單位毫秒 maxWait60000參數(shù)說明characterEncodingutf8mb4解決的是中文亂碼問題utf8mb4比utf8多覆蓋了 emoji 和特殊生僻字醫(yī)藥名里偶爾會出現(xiàn)這類字符。maxWait60000的意思是請求連接最多等 60 秒超過就拋異常而不是無限阻塞——演示現(xiàn)場最尷尬的畫面就是程序卡死在“獲取連接”這一步Java 線程池里一囤任務(wù)看起來像死機(jī)。maxActive20按課設(shè)體量綽綽有余別調(diào)成 100連接數(shù)過大反而拖垮 MySQL。有個常見的玄學(xué)現(xiàn)象本地用 Navicat 跑 SQL 正常Java 程序查詢中文全變問號。十有八九是 Navicat 導(dǎo)出腳本時的編碼和 JDBC URL 不一致導(dǎo)出時選 UTF-8連接串也寫 UTF-8兩邊對齊就不亂碼。4. 視圖、報(bào)表與權(quán)限讓課設(shè)看起來像一個系統(tǒng)只做單表增刪改查答辯大概率被批“像大作業(yè)”。真正讓醫(yī)藥管理系統(tǒng)“系統(tǒng)感”出來的是三個東西能主動發(fā)現(xiàn)問題的視圖、能出報(bào)表的聚合查詢、以及能說清楚的權(quán)限模型。這一章給出這三塊的落地寫法。4.1 快過期藥品提醒把“再過 90 天失效”變成一條查詢醫(yī)藥系統(tǒng)區(qū)別于一般進(jìn)銷存的核心場景是效期管理。一張藥品庫存表里有批號和效期但人工去盯太原始。用一個視圖把“臨期藥品”算出來Java 端直接SELECT * FROM v_expiring_drugs既簡單又能在答辯時講“用視圖屏蔽了復(fù)雜條件”。CREATE VIEW v_expiring_drugs AS SELECT d.drug_code, d.drug_name, s.batch_no, s.expire_date, s.quantity, DATEDIFF(s.expire_date, CURDATE()) AS remain_days FROM drug_stock s JOIN drug_info d ON s.drug_id d.id WHERE s.expire_date BETWEEN CURDATE() AND DATE_ADD(CURDATE(), INTERVAL 90 DAY) AND s.quantity 0 ORDER BY s.expire_date ASC;DATE_ADD(CURDATE(), INTERVAL 90 DAY)是 MySQL 的日期函數(shù)90 天這個閾值你可以改成180或30改成參數(shù)后更適合做“預(yù)警策略”。視圖的好處是條件只維護(hù)在一處Java 端的查詢代碼不會到處散落expire_date判斷。這個視圖在 ER 圖里不需要畫出來但報(bào)告里寫一段“基于視圖的臨期預(yù)警模塊”會讓評委老師覺得你對數(shù)據(jù)庫的掌握超出“會建表”一個層級。4.2 月度銷售統(tǒng)計(jì)GROUP BY 與日期索引的一個典型配合報(bào)表是數(shù)據(jù)庫課設(shè)的高頻考點(diǎn)。下面這條 SQL 統(tǒng)計(jì)最近 30 天每個藥品的銷售數(shù)量和銷售額SELECT d.drug_code, d.drug_name, SUM(i.quantity) AS total_qty, SUM(i.amount) AS total_amount, COUNT(DISTINCT o.id) AS order_count FROM sales_order_item i JOIN sales_order o ON o.id i.order_id JOIN drug_info d ON d.id i.drug_id WHERE o.create_time DATE_SUB(CURDATE(), INTERVAL 30 DAY) AND o.sale_status 1 GROUP BY d.drug_code, d.drug_name ORDER BY total_amount DESC LIMIT 20;關(guān)鍵點(diǎn)有兩個第一WHERE o.create_time ...如果量大了必須配合sales_order.create_time上的索引否則每次統(tǒng)計(jì)都全表掃第二GROUP BY的列要和SELECT的非聚合列一致drug_code、drug_name否則在 MySQL 5.7 以上會直接報(bào)ONLY_FULL_GROUP_BY錯誤這是課設(shè)里被問爆的一個報(bào)錯后面避坑章會專門展開。這里還有一個面試官愛問的優(yōu)化點(diǎn)COUNT(DISTINCT o.id)在數(shù)據(jù)量大時開銷不小如果只是演示可以去掉這個字段或改成“訂單數(shù) ≈ 明細(xì)條數(shù)”減少一層計(jì)算。報(bào)表類 SQL 要在“演示夠用”和“理論正確”之間取平衡真拿千萬級數(shù)據(jù)來壓LIMIT 20 只是保底手段。4.3 權(quán)限模型三張表解決“誰說能看報(bào)表”醫(yī)藥管理系統(tǒng)繞不開的角色無非是“系統(tǒng)管理員”“藥房操作員”“報(bào)表查看者”。如果你的課設(shè)只有一張登錄表和一段if (username.equals(admin))數(shù)據(jù)庫層就太單薄了。常見做法是用最樸素的 RBAC基于角色的訪問控制——三張表-- 用戶表 CREATE TABLE sys_user ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(30) NOT NULL UNIQUE, password_hash VARCHAR(64) NOT NULL, real_name VARCHAR(20), role_id INT NOT NULL ); -- 角色表 CREATE TABLE sys_role ( id INT AUTO_INCREMENT PRIMARY KEY, role_name VARCHAR(30) NOT NULL UNIQUE, role_desc VARCHAR(100) ); -- 菜單/功能權(quán)限表user 通過 role 獲得權(quán)限 CREATE TABLE sys_menu ( id INT AUTO_INCREMENT PRIMARY KEY, menu_code VARCHAR(50) NOT NULL UNIQUE, menu_name VARCHAR(50), parent_id INT DEFAULT 0 ); -- 角色-菜單關(guān)聯(lián)表 CREATE TABLE sys_role_menu ( role_id INT NOT NULL, menu_id INT NOT NULL, PRIMARY KEY (role_id, menu_id) );三張實(shí)體表再加一張關(guān)聯(lián)表登錄之后查一次角色再查一次菜單集合就能在前端控制“操作員看不到成本價、只有管理員能點(diǎn)盤點(diǎn)”。注意password_hash字段這里只放了 64 字符占位實(shí)際課設(shè)里可以直接用 Java 的BCrypt或SHA-256但一定要在報(bào)告里寫清楚“沒有存明文密碼”——這一句話就能避開答辯時“你這密碼安全嗎”的追問。5. 避坑手冊醫(yī)藥系統(tǒng)里最容易翻車的 5 個點(diǎn)這一章寫給已經(jīng)建完表、正準(zhǔn)備聯(lián)調(diào)的你。以下 5 個坑都是真實(shí)出現(xiàn)過的每一條都用“現(xiàn)象→原因→解決”的方式展開對著排查能省下一個通宵。5.1 金額算錯float 浮點(diǎn)精度引發(fā)的“對不上賬”現(xiàn)象銷售訂單明細(xì)里顯示單價 9.9 元數(shù)量 3 盒總金額卻是 29.699999 元。明細(xì)單條看不出來月度匯總一跑小數(shù)位全亂。原因建表時把price、amount定義成了FLOAT。浮點(diǎn)數(shù)是二進(jìn)制近似存儲9.9 在內(nèi)存里并不是精確的 9.9乘 3 之后誤差被放大。解決金額列全部改成DECIMAL(10,2)庫存數(shù)量按實(shí)際業(yè)務(wù)用DECIMAL(12,3)或INT。已經(jīng)建錯表的用ALTER TABLE sales_order_item MODIFY price DECIMAL(10,2);逐列改。這個坑的隱蔽之處在于數(shù)據(jù)量小的時候肉眼看不出問題直到報(bào)表對賬才暴露。5.2 外鍵刪除失敗刪分類時被“正在使用”卡住現(xiàn)象點(diǎn)擊刪除某個藥品分類程序報(bào)Cannot delete or update a parent row: a foreign key constraint fails或者干脆在DELETE時卡住。原因分類表drug_category被drug_info.category_id外鍵引用系統(tǒng)拒絕刪除“有子數(shù)據(jù)的父記錄”。這不是 MySQL 故障是外鍵機(jī)制在起作用但新手往往不知道看完整錯誤信息。解決三個選項(xiàng)任選。第一業(yè)務(wù)上禁止物理刪除用is_deleted TINYINT DEFAULT 0邏輯刪除這是醫(yī)藥系統(tǒng)最推薦的做法第二先清空該類下所有藥品再刪分類第三刪除前把子表數(shù)據(jù)轉(zhuǎn)移到其他分類。答辯時看到這個報(bào)錯別慌順著外鍵關(guān)系說一句“這是數(shù)據(jù)庫在保護(hù)引用完整性”反而加分。5.3 并發(fā)下單把庫存扣成負(fù)數(shù)現(xiàn)象兩個客戶端同時售出同一種藥品最終庫存變成 -1但界面沒有任何報(bào)錯。我和很多同學(xué)一樣在這地方吃過虧。原因代碼只有“先 SELECT 庫存再 UPDATE 庫存”兩個請求同時讀、后寫的覆蓋了前寫的更新。SELECT 和 UPDATE 之間根本不是原子操作。解決回到 3.1 節(jié)那條UPDATE ... WHERE quantity ?的方式。就算 UPDATE 一行數(shù)據(jù)庫會對命中行加鎖第二次請求會等待第一次提交后才執(zhí)行要么扣減成功、要么影響行數(shù)為 0 被回滾。不要在事務(wù)里先 SELECT 再 UPDATE 來“實(shí)現(xiàn)業(yè)務(wù)判斷”。5.4 中文亂碼Navicat 里好端端Java 一讀就是問號現(xiàn)象在 Navicat 查詢窗口執(zhí)行INSERT中文正常同樣的表用 Java 程序插入庫存表里的藥品名變成???。原因連接字符集不一致。常見的是 JDBC URL 沒帶characterEncoding或者 MySQL 服務(wù)端character_set_server仍是 latin1。解決三步對齊。第一步MySQL 庫、表統(tǒng)一utf8mb4第二步JDBC URL 寫法是jdbc:mysql://localhost:3306/pharma_sys?useUnicodetruecharacterEncodingutf8mb4第三步如果用的是 Druid 連接池確認(rèn)connectionProperties里沒有覆蓋掉 URL 的編碼參數(shù)。這個坑 95% 靠第二步解決剩下 5% 是代碼里建 Statement 時手動指定USE NAMES utf8mb4。5.5 GROUP BY 報(bào)錯明明查詢字段都對了還是提示 1055現(xiàn)象跑月度統(tǒng)計(jì)報(bào)表時MySQL 報(bào)Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column錯誤碼 1055。原因MySQL 5.7 及以上默認(rèn)開啟ONLY_FULL_GROUP_BYSQL 模式要求 SELECT 的非聚合列必須出現(xiàn)在 GROUP BY 里或者被聚合函數(shù)包住。解決先把 SQL 寫成規(guī)范形式列出所有非聚合列如GROUP BY d.drug_code, d.drug_name。因?yàn)閐rug_code和drug_name都在 SELECT 里就得都寫進(jìn) GROUP BY。如果只是想在課設(shè)演示時快速跑通臨時修改sql_mode去掉ONLY_FULL_GROUP_BY也行但報(bào)告里最好別拿出來說——答辯老師通常認(rèn)為這是治標(biāo)不治本的妥協(xié)。6. 驗(yàn)收自測課堂演示前要跑通的三個場景系統(tǒng)寫完后給自己做一次“模擬驗(yàn)收”。這一步的價值在于把數(shù)據(jù)庫層面的特性真正演示出來而不是靠 PPT 念一遍。下面這三個場景能覆蓋事務(wù)、并發(fā)、優(yōu)化三個高頻扣分點(diǎn)。第一個場景是事務(wù)回滾。開一個事務(wù)故意插入一個不存在的drug_id銷售明細(xì)存儲過程應(yīng)當(dāng)返回“藥品不存在”并整體回滾。驗(yàn)證方法很簡單事務(wù)執(zhí)行前記錄sales_order的最大 id執(zhí)行失敗后重新查詢該 id 不存在sales_order_item中也沒有半截?cái)?shù)據(jù)。答辯時說“要么全部成功要么全部不成功”這句話就是用START TRANSACTION和ROLLBACK頂起來的。第二個場景是并發(fā)扣庫存。準(zhǔn)備一個庫存量為 10 的藥品開兩個客戶端同時各買 6 盒。結(jié)果應(yīng)當(dāng)是一個成功、一個提示庫存不足最終庫存為 4 而不是 -2。這里要向老師指出成功方用UPDATE ... WHERE quantity ?拿到行鎖失敗方等待鎖釋放后匹配不到記錄影響行數(shù)為 0 被回滾。我強(qiáng)烈建議在答辯前實(shí)際演示一次因?yàn)椴l(fā)的不確定性會讓很多“理論上正確”的程序當(dāng)場翻車。第三個場景是慢查詢分析。先在sales_order.create_time建索引再跑月度銷售統(tǒng)計(jì) SQL執(zhí)行EXPLAIN看type和rowsEXPLAIN SELECT ... FROM sales_order_item i JOIN sales_order o ON o.id i.order_id WHERE o.create_time 2024-01-01;重點(diǎn)關(guān)注三列type是否為ref或rangekey是否真的用了idx_create_timerows是否遠(yuǎn)小于全表行數(shù)。如果顯示ALL全表掃描就是索引沒生效最常見原因是 WHERE 條件里的列和索引列類型不一致或者create_time在函數(shù)里包了一層。這個EXPLAIN跑完數(shù)據(jù)庫優(yōu)化這一塊的分?jǐn)?shù)基本就拿到了。最后說一個每次答辯都會被追問的細(xì)節(jié)備份與恢復(fù)。課設(shè)報(bào)告里寫清楚“用mysqldump做每日備份恢復(fù)時用SOURCE導(dǎo)回”再加上一句“實(shí)際生產(chǎn)環(huán)境不能只靠單機(jī)備份”。醫(yī)藥數(shù)據(jù)屬于強(qiáng)監(jiān)管數(shù)據(jù)這句話能讓你和只寫了一堆 CRUD 的同學(xué)明顯拉開距離。我在做這類系統(tǒng)的課設(shè)時養(yǎng)成的一個習(xí)慣是在每個核心表上都留一個create_time和update_time字段哪怕當(dāng)時用不上。后面加審核、加審計(jì)、加數(shù)據(jù)對比都會感謝當(dāng)時的這個決定。數(shù)據(jù)庫課設(shè)最怕的不是功能少而是不給自己留余地。希望這份從建表到避坑的整套做法能幫到你至少讓你在后半夜聯(lián)調(diào)時少走兩條彎路。本文還有配套的精品資源點(diǎn)擊獲取