Why it is worth attention

It provides a meticulously structured, real-world-like engineering project that enforces strict database constraints, a five-layer backend architecture, and a complete business workflow (purchase, refund, market trading, achievements), serving as an exemplary reference for database course design.

Who it is for

Computer science students taking database course design
Educators looking for a comprehensive teaching case
Self-learners studying full-stack development with C#/.NET
Backend developers interested in Oracle and .NET integration

Use cases

Learning relational database design (27 tables, 3NF, constraints)
Practicing C#/.NET Web API development with Oracle
Simulating a game store with wallet, orders, market, and refunds
Experiencing team collaboration with Git branch and PR workflows

Strengths

Thorough database schema with 27 tables, primary/foreign keys, 40 foreign keys, 13 unique constraints, and 222 check constraints
Clear five-layer architecture (Controller, Application, Domain, Infrastructure, Shared) with strict layer dependency rules
Detailed team division and delivery specifications for each module
Complete business transaction coverage including idempotency, concurrency, and atomicity

Considerations

Non-production project intended for academic demonstration only
Tightly coupled to specific technologies (C#/.NET, Oracle, Vue 3) which limits technology stack diversity
Lacks real-time data sync with Steam and uses simulated demonstration data

README quick start

"Steam-" 数字游戏平台系统课程设计 README

本 README 是项目后续设计、开发、部署、验收和答辩的统一参考文件。
任何技术选型、部署方案、数据库结构、开发计划、实际实现与本文档不一致时，必须先更新 README，再继续开发。

协作铁律：普通组员禁止直接推送 main

main 分支是项目稳定主线，必须始终保持可运行、可演示、可用于答辩。

普通组员开发功能时必须遵守以下流程：

从 main 拉取最新代码
  -> 创建自己的功能分支
  -> 在功能分支提交代码
  -> 推送功能分支到 GitHub
  -> 发起 Pull Request
  -> 由总负责人检查代码、接口、数据库脚本、README 和演示流程
  -> 通过后合并进 main

GitHub 仓库已对 main 分支启用保护规则：

普通组员禁止直接 push 到 main。
禁止 force push。
禁止删除 main。
普通组员合并前必须通过 Pull Request。
普通组员 Pull Request 至少需要 1 个 review。
Pull Request 中未解决的讨论必须先处理完。
总负责人马祥珲本人，或经马祥珲明确授权由 Codex 完成且已通过构建/测试/安全检查的提交，可以由管理员直接合并到 main，不需要等待 Pull Request 审批。
其他组员提交的业务代码仍必须走 Pull Request 审查流程。

任何数据库表结构、公共接口、统一响应格式、技术路线、部署方案、团队分工和交付规范变更，都必须在 Pull Request 中同步更新 README。

技术路线和分工属于总负责人统一管理的项目级决策：

组员不能在功能 PR 中自行修改技术路线、系统架构、团队分工、模块边界和交付规范。
未经马祥珲明确确认，不得把 C# / .NET / Oracle / B/S、五层结构、前端技术方向、组别职责或总负责人规则改掉。
未经马祥珲明确确认，不得更换最终样板游戏。当前最终样板游戏固定为 Counter-Strike 2 和 Don't Starve Together / 饥荒联机版。
如果确实认为既定方案需要调整，必须先提出单独讨论，不得夹带在功能代码 PR 中直接改 README。

1. 最高约束：课程提纲

本项目必须严格遵守 2026《数据库课程设计》课程提纲.doc 的要求。

课程提纲中的关键硬要求：

使用 VS.NET 较新版本。
使用 C# 语言。
使用 Oracle 18c 或更高版本作为 DBMS。
使用 Oracle 数据访问组件或 ORM 框架。
开发一个实用的信息管理系统。
C/S 或 B/S 均可。
至少 12 张表，且符合第三范式。
至少 20 个功能点，其中至少 15 个功能点必须具有一定业务逻辑，不能只是表的增删改查。
编码实现课程项目，并进行测试，部署或生成可执行程序。
撰写系统需求分析文档、系统设计与实现文档、答辩 PPT。
评分关注工作量、应用性、复杂性、总体设计、功能完整性、数据库合理性、界面美观、编码规范、鲁棒性、扩展性、文档质量和答辩表现。

本项目额外确定的约束：

架构选择 B/S。
除前端界面外，后端、应用服务器、数据访问层、部署脚本等项目实现均使用 C# / .NET 技术栈。
数据库和应用服务器均部署到腾讯云云服务器。
前端继续使用 Vue 技术栈实现 Steam 风格界面。

废弃旧计划：

不再使用 Spring Boot。
不再使用 Java 作为后端语言。
不再使用 Maven 作为项目构建主线。
不再使用 MyBatis / MyBatis-Plus。
不再使用 Tomcat / HikariCP / Spring Security。

2. 当前项目定位

本项目实现一个类似 Steam 的数字游戏平台系统。系统不仅要完成基础游戏商店功能，还要体现数据库课程设计重点：关系模型、约束、事务、一致性、日志、审计、幂等、防并发、资产确权和复杂业务流程。

核心业务域：

玩家账号与权限。
开发商与管理员。
游戏商店与公告。
钱包账户与资金流水。
游戏订单、订单明细、支付流水、订单状态日志。
退款申请、退款明细、退款审核日志。
玩家游戏库与数字资产确权。
CDKey 批次、CDKey、兑换风控日志。
游戏评价主记录与评价历史版本。
成就字典与玩家成就解锁。
饰品模板、饰品实例、玩家库存。
饰品市场买卖挂单、撮合成交、资金清算、饰品流转账本。

2.1 最终样板游戏与统一业务口径

本项目最终只选用两款真实 Steam 游戏作为公开演示和测试数据口径：

游戏	Steam AppID	项目内定位	主要承载模块
`Counter-Strike 2`	`730`	饰品经济、库存、市场交易、热门免费游戏样板	饰品模板、饰品实例、库存、市场卖单/买单、成交、价格历史、Steam 风格详情页
`Don't Starve Together / 饥荒联机版`	`322330`	买断制联机生存、DLC/皮肤箱、创意工坊、社区样板	游戏购买、游戏库、DLC/礼包、评价、公告、创意工坊入口、社区讨论、成就模拟

选择依据：

Counter-Strike 2 Stea