Oracle学生考勤系统课程设计：12张表DDL避坑与数据库端实现-北京尧图网络

简介面向Oracle数据库课程设计场景的实践报告适合数据库管理与开发方向的学生及需要完成课程设计的读者参考。内容以“学生考勤系统”为主线围绕学生、任课老师、班主任、院系领导、学校领导、系统管理员等多角色需求梳理请假申请、考勤记录、后台管理等功能划分并依次展开E-R模型、数据字典、数据库表逻辑结构、表空间和表创建等设计环节呈现从需求分析到物理实现的完整链路。压缩包内共1个doc文件约227KB为按章节组织的课程设计报告文档便于对照查阅设计过程与文档写法。已有968人学习说明其在同类课程设计选题中具有一定参考价值报告还包含心得体会与参考文献可用于梳理设计思路、完善报告框架及查漏补缺。1. 拿到一份 Oracle 数据库课程设计先别急着从头跑 SQL很多人拆 Oracle 数据库课程设计这类资料习惯是从第一行 DDL 开始往下执行跑到第三张表就弹出 ORA-00907然后卡一下午。这份学生考勤系统的设计稿是很典型的样本需求分析、E-R 模型、数据字典、逻辑结构、物理实现一条线走完12 张表把院系、专业、班级、班主任、教师、学生、课程、请假单、考勤记录全串起来末尾还挂了存储过程、视图和触发器。它真正值钱的地方不是报告写得多整齐而是把「一个业务系统怎么在纯数据库层落地」这件事走完整了。适合两类人要交课程设计、需要一份能改能跑的原型的学生以及写了几年 CRUD、想把表设计基本功重新过一遍的后端开发。2. 系统骨架六类角色和三个模块怎么压进 12 张表这套设计的第一个看点不在代码在角色划分。很多同类作业把用户笼统分成「管理员普通用户」权限全靠应用层 if-else 挡数据库这边基本裸奔。这份稿子拆出了六类用户并且每一类用户的差异最终都能在表结构里找到落点这一点值得细看。2.1 六类用户的读写边界决定了每张表的归属把六类角色逐个摊开看它们对数据的动作表设计的轮廓就出来了角色主要写入主要读取数据范围学生qingjia提交请假kaoqin_record、qingjia仅本人任课老师kaoqin_record录考勤kaoqin_record、qingjia所教班级班主任qingjia 的班主任审批字段kaoqin_record、student本班院系领导qingjia 的院系审批字段kaoqin_record本院系学校领导无kaoqin_record全校系统管理员几乎所有表所有表全校这张表一画完两个设计决策就顺理成章了。第一请假单必须是一张宽表把两级审批的状态、审批人、审批时间全部塞进 qingjia因为审批动作本身就是对同一行记录的字段更新拆成审批流水表反而增加 join 成本课程设计这个量级没必要。第二考勤记录和请假单必须是两张表而不是一张因为它们的写入方不同、时间粒度不同、生命周期也不同——考勤记录按「一节课一个学生一条」膨胀请假单按「一次申请一条」增长混在一起字段会有一半常年为 NULL。我在实际项目里见过反过来的做法把请假状态直接做成考勤记录表里的一个 enum 值结果就是任课老师每节课都要手动把请假的学生标一遍出错率极高。这套设计把「谁录入」和「谁审批」分开是对的。2.2 请假流和考勤流的交汇点是整个设计里最值得抄的部分两条业务流的走向是这样的请假流学生填单 → 写入 qingjia两个审批状态字段初始为 0等待审批→ 班主任审批更新 class_tea_sp_status → 如果请假天数超过 3 天流转到院系领导更新 coll_leader_sp_status → 状态置 1 表示同意。考勤流任课老师按课表打开某节课的学生名单 → 逐条写入 kaoqin_recordstu_status 记「出勤 / 旷课 / 迟到」→ 写入瞬间触发器介入统计该生该课程的累计异常次数 → 超过阈值给出提示。交汇点在考勤录入那一步如果一个学生当天有已批准的请假单任课老师录考勤时这个学生应该被自动标成「请假」而不是「旷课」否则后面所有统计都是错的。原稿没有把这段逻辑写死但 qingjia 表里的 start_time、end_time 和 kaoqin_record 里的 sk_time 已经具备了做区间判断的全部条件。常见做法是录考勤前先跑一条查询把当节课时间落在请假区间内、且两级审批都为 1 的学生先捞出来预置状态-- 录入某节课考勤前先捞出该时段内已批准请假的学生 select q.stu_no, q.id from qingjia q where q.class_tea_sp_status 1 -- 班主任已同意 and (q.coll_leader_sp_status 1 -- 院系已同意长假 or q.day_number 3) -- 或本来就不需要院系审批 and q.start_time to_date(:sk_time, yyyy-mm-dd hh24:mi:ss) and q.end_time to_date(:sk_time, yyyy-mm-dd hh24:mi:ss);class_tea_sp_status和coll_leader_sp_status用字符 0 / 1 / 2 表示等待、同意、不同意这个约定贯穿全表后面所有审批相关的判断都靠它。:sk_time是绑定变量传当节课的时间点比字符串拼接安全也更利于游标复用。提示状态字段用 char(1) 存数字字符是个历史习惯好处是可读性直观、导出报表不用翻译坏处是没有数据库层面的取值约束。真要做生产系统加一个check (class_tea_sp_status in (0,1,2))会省掉大量脏数据排查。2.3 权限为什么值得压到数据库层而不只是应用层菜单课程设计阶段最容易偷懒的地方就是权限。反正前端不给按钮用户点不到数据库这边就裸着。问题是考勤系统这类多角色系统天然存在「同一个视图不同人看到不同行」的需求院系领导只能看本院系的考勤学校领导能看全校。如果全靠应用层拼 where 条件一个拼接漏洞就是越权。原稿选择用视图来做行级隔离思路是对的。第 4 章会详细拆这个视图怎么写、有什么局限。这里先说结论视图能挡住「查错范围」这一类问题但挡不住「改错范围」写操作的行级控制还得靠触发器或者应用层校验兜底。课程设计能想到视图这一层已经合格二次开发时要补上写侧的控制。3. 从 E-R 模型到 12 张表的 DDL依赖顺序和字段类型E-R 图和数据字典在原稿里占了不小篇幅但真正能落地的只有第 5、6 章那批建表语句。这批语句信息量很足同时问题也不少正好可以当作「怎么从设计稿推 DDL」的样本。3.1 先定外键方向再定建表顺序十二张表之间的引用关系不是随便排的必须先理清谁是父表谁是子表院系 faculty 是根专业 major 引用 faculty班主任 classteacher 引用 major 和 faculty班级 classes 引用 classteacher学生 student 引用 classes、major、faculty。这条链是单向的所以建表顺序只能是 faculty → major → classteacher → classes → student。另一条链是教师 teacher 引用 faculty课程 course 独立考勤记录 kaoqin_record 同时引用 student、teacher、course所以它必须最后建。请假单 qingjia 引用 classes、student、classteacher、collegeleader也排在最后。建表顺序搞反报错是 ORA-00942表或视图不存在这个错误提示很难直接指向「你顺序错了」新手容易以为是权限问题。血泪经验是把依赖关系画成一张有向图按拓扑排序写脚本别凭印象排。3.2 表空间和存储参数一行 create tablespace 里的三个变量原稿先建表空间再建表这个顺序是对的。表空间的作用是把不同用途的对象物理隔离便于单独备份和监控磁盘。原稿给的语句是 Oracle 9i/10g 时代的字典管理表空间写法create tablespace kaoqin_data datafile /u01/oracle/oradata/kaoqin01.dbf -- 物理文件路径必须已存在且可写 size 100M -- 初始大小 default storage ( initial 512K -- 第一个区大小 next 128K -- 后续区大小 minextents 2 -- 最少分配 2 个区 maxextents 999 -- 最多 999 个区unlimited 表示不限制 pctincrease 0 -- 区增长百分比0 表示不自动递增 ) online;三个变量得注意。datafile的路径必须是服务器上真实存在、Oracle 进程有写权限的目录路径写错直接 ORA-01119。size定太小后面批量灌数据会频繁扩区。pctincrease 0这个设置在现代 Oracle 里其实已经没什么意义本地管理表空间LMT是默认行为default storage子句在 LMT 下会被忽略。真机环境用create tablespace kaoqin_data datafile ... size 100M autoextend on next 32M maxsize 2G;更省心。后面所有建表语句末尾都带tablespace kaoqin_data这是把对象指定到刚建的表空间里不写的话会落到用户默认表空间。3.3 组织架构和人员表char 和 number 的混用要当心先看第一组建表语句负责组织架构和人员-- 院系表整个系统的根节点 create table faculty ( faculty_id number not null, faculty_name char(10) not null, constraint pk_faculty primary key (faculty_id) ) tablespace kaoqin_data; -- 专业表属于某个院系 create table major ( major_id number not null, major_name char(20) not null, major_faculty number not null, constraint pk_major primary key (major_id), constraint fk_major_faculty foreign key (major_faculty) references faculty(faculty_id) ) tablespace kaoqin_data; -- 学生表同时引用班级、专业、院系三个父表 create table student ( stu_no char(10) not null, stu_name varchar2(30) not null, stu_sex char(2) check (stu_sex in (男,女)), stu_class char(10) not null, stu_major number not null, stu_faculty number not null, constraint pk_student primary key (stu_no), constraint fk_stu_class foreign key (stu_class) references classes(class_no), constraint fk_stu_major foreign key (stu_major) references major(major_id), constraint fk_stu_faculty foreign key (stu_faculty) references faculty(faculty_id) ) tablespace kaoqin_data;这里我把原稿的写法改了四处改完才能跑。第一处是外键。原稿写的是stu_class char(5) foreign key references classes(class_no)这种「列名类型 foreign key references 表(列)」的内联写法在 MySQL 里成立Oracle 不认执行会报 ORA-00907 缺失右括号。Oracle 的列级约束只允许写references classes(class_no)foreign key关键字要放到表级 constraint 里。第二处是varchar。Oracle 建表时varchar会被悄悄转成varchar2不报错但容易让人误以为两者等价。PL/SQL 里的varchar和 SQL 里的varchar2是两回事统一写varchar2省心。第三处是长度。stu_class原稿写char(5)但 classes 表的主键class_no是char(10)父子列长度不一致外键一样能建成功只是 char 会用空格补齐后面用比较时容易因为尾随空格匹配不上。这个坑非常隐蔽查询突然查不出数据排查半天才发现是 char 补空格。第四处是stu_sex char(2)存中文。在 ZHS16GBK 字符集下男占 2 字节刚好够在 AL32UTF8 下占 3 字节插入直接 ORA-12899 值太大。稳妥写法是char(3)或者干脆用char(1)存 M/F。这个取决于你建库时的字符集动手前先执行select value from nls_database_parameters where parameterNLS_CHARACTERSET;确认一下。人员表里还有 teacher、classteacher、admin、collegeleader、schoolleader 五张结构思路一致编号做主键姓名、性别、职称、所属院系做属性性别统一加 check 约束。classteacher 稍微特殊它同时引用 major 和 faculty相当于把「这个班主任是哪个专业哪个学院的」固化下来。3.4 业务表考勤记录和请假单字段最多的两张第三组是业务表也是整个系统跑起来之后增长最快的两张-- 课程表考勤记录的引用目标之一 create table course ( course_no char(13) not null, course_name varchar2(20) not null, course_xz char(4) not null, -- 课程性质必修/选修/限选 constraint pk_course primary key (course_no) ) tablespace kaoqin_data; -- 考勤记录表一节课一个学生一条 create table kaoqin_record ( kaoqin_id char(13) not null, sk_time date not null, -- 原稿写 datetimeOracle 无此类型 stu_number char(10) not null, stu_status varchar2(10) not null, -- 出勤/旷课/迟到/请假 teacher_no char(10) not null, course_no char(13) not null, constraint pk_kaoqin primary key (kaoqin_id), constraint fk_kq_stu foreign key (stu_number) references student(stu_no), constraint fk_kq_tea foreign key (teacher_no) references teacher(tea_no), constraint fk_kq_course foreign key (course_no) references course(course_no) ) tablespace kaoqin_data; -- 请假单表两级审批字段全部内联 create table qingjia ( id number not null, class_id char(10) not null, stu_no char(10) not null, leave_reason varchar2(200) not null, start_time date not null, end_time date not null, day_number number not null, qingjia_time date not null, class_tea_id char(5), class_tea_sp_status char(1) default 0, class_tea_sp_time date, coll_leader_sp_status char(1) default 0, coll_leader_id char(5), coll_leader_sp_time date, constraint pk_qingjia primary key (id), constraint fk_qj_class foreign key (class_id) references classes(class_no), constraint fk_qj_stu foreign key (stu_no) references student(stu_no), constraint fk_qj_ctea foreign key (class_tea_id) references classteacher(classtea_no), constraint fk_qj_clead foreign key (coll_leader_id) references collegeleader(collegeleader_no), constraint ck_qj_status check (class_tea_sp_status in (0,1,2) and coll_leader_sp_status in (0,1,2)), constraint ck_qj_days check (day_number between 0.5 and 31) ) tablespace kaoqin_data;改动集中在三处。datetime换成了dateOracle 没有datetime类型建表直接 ORA-00902 无效数据类型这是原稿最显眼的硬伤也是从 SQL Server / MySQL 思维迁移过来最常见的翻车点。day_number加了check约束请假最长不超过一个月这条业务规则终于落到了数据库上而不是只写在报告里。审批状态字段加了取值约束避免出现 3、是、同意这种五花八门的值。kaoqin_id和id用 char 和 number 做主键没有用序列自增。课程设计这个量级手写编号没问题真要用起来给 qingjia 加一个序列配合触发器做自增会省事create sequence seq_qingjia start with 1 increment by 1; create or replace trigger trg_qingjia_id before insert on qingjia for each row begin if :new.id is null then select seq_qingjia.nextval into :new.id from dual; end if; end; /:new是行级触发器的伪记录代表即将插入的那一行。before insert的时机很关键换成 after 就改不动主键了。4. 数据库端三件套存储过程、视图、触发器的实际写法这三样东西是把业务逻辑往数据库下沉的典型手段原稿的思路都对语法和统计口径上有些问题逐个拆。4.1 出勤统计存储过程参数命名和赋值符号都是坑原稿的存储过程想做的是「给定学生和课程统计缺勤次数」create or replace procedure get_absence_stat ( p_stu_no in varchar2, -- 学生学号 p_course_no in varchar2, -- 课程编号 p_total out number, -- 总记录数也就是总课时 p_absent out number -- 缺勤次数 ) as begin select count(*) into p_total from kaoqin_record where stu_number p_stu_no and course_no p_course_no; select count(*) into p_absent from kaoqin_record where stu_number p_stu_no and course_no p_course_no and stu_status 旷课; -- 关键必须按状态过滤 end; /原稿写的是total_timesabsence_times;两个问题赋值符号在 PL/SQL 里是:等号只在 SQL 语句的 where / set 里用另外参数声明outnumber中间少了空格out number才是完整写法。参数命名上我全部加了p_前缀。这不是洁癖是躲一个非常隐蔽的 bug如果参数直接叫stu_no而表里有个列叫stu_number看起来不冲突但一旦列名和参数名撞车PL/SQL 默认优先解析成列名查询条件会变成where stu_no stu_no永远为真统计结果恒等于全表。加了前缀就彻底没这个风险。另一个改进是把「总记录数」和「缺勤次数」拆成两个出参。原稿只统计总数可「这个学生这门课请了几次假、旷了几次课」才是学生和班主任真正想看的。一次调用返回全部口径比调四次省事。调用方式declare v_total number; v_absent number; begin get_absence_stat(0820980113, ORACLE001, v_total, v_absent); dbms_output.put_line(总课时: || v_total || 旷课: || v_absent); end; /4.2 院系隔离视图拿视图切行别拿 where 切院系领导只能看本院学生的考勤这个需求用视图实现-- 院系维度的基础视图把学生和考勤拼在一起带上院系标识 create or replace view v_kaoqin_detail as select k.kaoqin_id, k.sk_time, k.stu_number, s.stu_name, s.stu_faculty, k.stu_status, k.teacher_no, k.course_no from kaoqin_record k join student s on s.stu_no k.stu_number; -- 软件学院专用视图faculty_id 5 为例 create or replace view v_kaoqin_faculty_5 as select * from v_kaoqin_detail where stu_faculty 5; -- 授权只给该院系领导账号查询权限 grant select on v_kaoqin_faculty_5 to role_college_leader_5;原稿是直接写死了student.stu_faculty5的单表视图思路完全一样只是我把公共的 join 部分抽成基础视图各院系视图基于它过滤后面加院系只需要再写一行 create view不用重复抄 join。这种做法的局限必须说清楚视图的数量会随着院系数量线性增长二十个院系就要二十个视图和二十次授权维护起来很累。真实项目里更常见的做法是应用层传院系 ID 做参数化查询数据库侧用虚拟专用数据库VPD策略函数在行级自动附加谓词一次配置全局生效。课程设计用视图做演示是够的二次开发时如果院系会动态增减就得考虑换方案。注意视图只解决读。如果某类用户还能写行级写入控制得靠 instead of 触发器或者应用层校验视图本身不具备拦截能力。4.3 缺勤超限触发器dbms_output 只能当调试输出原稿想做的是「某学生某课程缺勤超过 3 次就提示取消考试资格」create or replace trigger trg_alert_absence after insert on kaoqin_record for each row declare v_absent number; begin -- 只统计旷课不要把请假、迟到也算进去 select count(*) into v_absent from kaoqin_record where stu_number :new.stu_number and course_no :new.course_no and stu_status 旷课; if v_absent 3 then -- 生产环境应写入告警表这里保留输出便于课程演示 dbms_output.put_line( 学号 || :new.stu_number || 课程 || :new.course_no || 累计旷课 || v_absent || 次已达取消考试资格线); end if; end; /原稿的统计条件里没有stu_status 旷课这会导致学生请假次数多了也被判定为要取消资格属于统计口径错误——这类 bug 在演示时看不出来上线后被学生投诉才发现。加上状态过滤才算对。dbms_output.put_line的输出只有在 SQL*Plus 或支持 dbms_output 的客户端里set serveroutput on之后才看得到应用层通过 JDBC 调过来的写入根本收不到这条「提示」。所以真要用得建一张告警表把事件落下来create table exam_disqualify_warn ( warn_id number generated by default as identity, stu_no char(10) not null, course_no char(13) not null, absent_cnt number not null, warn_time date default sysdate, handled char(1) default 0, constraint pk_warn primary key (warn_id) ); -- 触发器里改成写入 insert into exam_disqualify_warn(stu_no, course_no, absent_cnt) values (:new.stu_number, :new.course_no, v_absent);拿表落事件比 println 靠谱得多后面还能挂个定时任务统一推送或者做成报表给教务看。这个改动很小但把「提示」变成了「可追溯的记录」性质完全不一样。5. 避坑排查这份 DDL 照抄会在第几行报错原稿的建表语句我从头对着敲过一遍报错点比较集中把最容易卡住的五条列出来。5.1 ORA-00907外键内联写法 Oracle 不认现象执行create table student(...)时在stu_class char(5) foreign key references classes(class_no)这一行报 ORA-00907 缺失右括号错误位置指向括号附近看不出是外键问题。原因MySQL 支持「列名类型 foreign key references 父表(列)」这种内联语法Oracle 的列级约束只认references 父表(列)foreign key是表级约束关键字位置摆错就语法错。解决两个改法任选。列级写stu_class char(10) references classes(class_no)或者统一挪到表级constraint fk_stu_class foreign key (stu_class) references classes(class_no)。我倾向于后者约束都集中在表定义末尾出问题一眼能找到。5.2 ORA-00902datetime 不是 Oracle 的数据类型现象sk_time datetime not null直接报 ORA-00902 无效的数据类型。原因datetime是 SQL Server 和 MySQL 的类型名Oracle 里对应的是date精确到秒或timestamp精确到小数秒。这个错误往往是整份脚本里第一个拦路虎因为 DDL 一旦报错后面的表全建不成容易误以为是环境问题。解决全部换成date。考勤场景精确到秒就够了不需要 timestamp。顺带检查所有varchar出现的地方统一改varchar2。5.3 ORA-12899char(2) 存不下一个汉字现象往性别字段插入男时报 ORA-12899 值对于列太大明明只插了一个字符。原因char 的长度单位默认是字节。GBK 字符集一个汉字占 2 字节char(2) 刚好UTF8 字符集一个汉字占 3 字节char(2) 就装不下。开发机和生产库字符集不一致时本地跑得好好的脚本一部署就炸。解决先查nls_database_parameters确认字符集UTF8 环境把性别字段改成char(3)或者用char(2 char)显式声明按字符计长。更彻底的做法是存 M/F 这种单字节值前端负责翻译显示。5.4 ORA-01119表空间数据文件路径不存在现象create tablespace报 ORA-01119 创建数据库文件失败附带的 ORA-27040 提示无法创建文件。原因脚本里的/u01/oracle/oradata/xxx.dbf是别人机器上的路径你的环境根本没有/u01这个目录或者 Oracle 进程对该目录没有写权限。解决先show parameter db_files和select name from v$datafile;看一眼现有数据文件放在哪照葫芦画瓢改路径。Windows 环境写成D:\oracle\oradata\kaoqin01.dbf。如果只是本地练手直接跳过建表空间用默认的 USERS 表空间把建表语句末尾的tablespace子句删掉也能跑。5.5 外键建表顺序错ORA-00942 追不到根因现象建 classes 表时报 ORA-00942 表或视图不存在但 classes 明明是下一句才建语法也没错。原因classes 引用了 classteacherclassteacher 又引用了 major 和 faculty脚本顺序如果按报告章节排而不是按依赖排父表还没建就引用了。解决按「faculty → major → classteacher → classes → student」、「course / teacher → kaoqin_record」、「classes / student / classteacher / collegeleader → qingjia」三组顺序写脚本。或者干脆把所有外键约束从 create table 里摘出来等十二张表全建完再用一堆alter table ... add constraint ...统一加顺序问题一次性消失缺点是脚本变长。6. 二次开发把它从「能交差」推到「能演示」这套设计的骨架是完整的缺的是把它变成一个能演示、能继续加功能的系统。改造我按优先级列了个清单优先级改造项具体动作验证方式高告警落表建 exam_disqualify_warn触发器改写表造 3 条旷课记录查告警表有数据高主键自增qingjia、kaoqin_record 加序列 before insert 触发器不传 id 直接 insert检查 id 有值中统计视图建 v_stu_absence_stat按学生课程聚合出勤/请假/旷课对比明细表手工 count 结果中字符集适配全表 grep 一遍 char(n) 存中文的位置统一改字节或字符语义在 UTF8 库上重跑建表脚本低应用层用任意 Web 框架接上登录分流六个角色每类角色各点一遍主要页面造数据脚本建议单独建一个init_data.sql把院系、专业、班级、学生、课程、课表的样例数据按依赖顺序灌进去。这一步很容易被忽略结果演示时页面空空评委一问就露馅。数据量不用多一个院系两个专业三个班每班十个学生两门课一个学期十六节课够跑出所有报表了。验证改造是否生效别靠肉眼看界面直接写断言查询-- 校验每个学生的考勤总数出勤请假迟到旷课 select stu_number from (select stu_number, count(*) total, count(case when stu_status in (出勤,请假,迟到,旷课) then 1 end) valid from kaoqin_record group by stu_number) where total valid; -- 有结果说明存在脏状态值这条查询跑出来是空集才说明状态字段没被写进意料之外的值。存储过程和触发器的口径问题用这种方式回归比点页面可靠得多。我在做这类数据库层改造时有个固定习惯任何统计口径的改动先在明细表上用 SQL 手工算出期望值再和存储过程或视图的结果比对两边一致才算改完。这步多花五分钟能省掉后面被追问「这个数字怎么对不上」的一整个下午。从那以后我每次动统计类逻辑都强制走一遍「手工 SQL 对照」的流程跳过一次就翻车一次。希望帮到你。本文还有配套的精品资源点击获取

Oracle学生考勤系统课程设计：12张表DDL避坑与数据库端实现

相关推荐

C语言理论考题库高频易错点与考前复习清单

智能交通系统中的机器学习应用与优化

鸽巢原理：从基础概念到计算机科学应用

更多资讯

揭秘电商智能系统：从选品到私域的全链路优化

MoE混合专家模型：稀疏激活、路由机制与推理部署优化全解析

AI Agent专用数据库MemoryDB架构与实战

云端计算在气象干旱监测中的应用与SPI分析实践

Zcode OSS上传风波复盘：从抓包误读到harness诊断机制的技术真相

curl命令分层实战：接口调试、耗时打点与自动化脚本

今日更新

AI辅助技术栈评估：提升研发决策效率60%

从生成Token到直接决策：Jev如何重塑AI Agent工程实践

32G统一内存跑大模型：内存账、TPS实测与端云分流

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？