# 09 方案比较与选型依据 ## 9.1 编写目的 课程设计大纲明确要求：应对选题及设计方案进行比较分析，并给出最终结论。因此，本章用于说明本课题在需求分析阶段考虑过哪些主要备选方案，以及为什么最终选择当前路线。 ## 9.2 课题范围方案比较 ### 方案一：继续覆盖全部历史模块 方案描述： - 将通知公告、问卷、投票、材料收集、失物招领、功能房预约、课程资源、图书馆等全部纳入本轮主线 优点： - 功能覆盖面广 - 工程展示内容看起来较丰富 缺点： - 范围过大，难以形成深入的数据库分析 - 需求分析容易变成功能罗列 - 报告与答辩重点分散，不利于突出数据库主线 ### 方案二：聚焦数据库主线模块 方案描述： - 题目保持为“校园生活平台” - 主线收束为平台基础、功能房预约、课程资源分享 - 数字图书馆作为可选扩展 优点： - 能够突出数据库课程设计重点 - 便于形成完整、深入、规范的需求分析与数据库设计 - 更符合老师强调的“复杂业务建模”要求 缺点： - 无法在本轮报告中全面展示全部历史模块 ### 选择结论 本课题采用方案二，即“题目不变、范围聚焦”的策略。 ## 9.3 数据库运行环境方案比较 ### 方案一：完全迁移为本地 PostgreSQL 环境 优点： - 更符合传统数据库课程的实验环境直觉 - 可在答辩时更直接地说明“本地 PostgreSQL 实例”这一运行形态 缺点： - 需要额外投入环境迁移和适配成本 - 会分散本轮课程设计在需求分析与数据库建模上的精力 ### 方案二：以标准 PostgreSQL 为数据库内核，当前项目继续运行在兼容环境中 方案描述： - 数据库设计与 SQL 表达均以标准 PostgreSQL 能力为准 - 当前工程运行环境可继续使用托管 PostgreSQL 服务 - 在报告和答辩中强调“PostgreSQL 数据库设计”，而非强调托管平台本身 优点： - 不影响数据库课程设计主线 - 可复用现有工程基础 - 既保留实现便利性，又能保持数据库设计表达的规范性 缺点： - 需要在报告中明确区分“数据库内核”和“运行平台” ### 选择结论 本课题采用方案二。即：设计口径统一按 PostgreSQL 展开，运行环境只作为支撑，不作为数据库设计亮点。 ## 9.4 身份认证方案比较 ### 方案一：完全自建认证系统 优点： - 身份生命周期完全自控 - 所有认证相关表结构都可自行定义 缺点： - 需要投入大量时间处理密码、会话、邮件验证等工程细节 - 容易削弱数据库课程设计对核心业务建模的关注 ### 方案二：使用现有身份事实源，重点设计业务数据库 方案描述： - 使用现有身份事实源支撑注册、登录与认证 - 在业务数据库中重点设计用户资料、组织、角色、权限、数据范围、审计和业务表 优点： - 聚焦数据库主线 - 降低重复造轮子成本 - 更利于把精力投入复杂业务建模 缺点： - 需要在报告中解释“身份事实源”和“业务资料扩展”的边界 ### 选择结论 本课题采用方案二。在答辩中应强调：课程设计重点不在重写认证链路，而在展示数据库对业务的建模和约束能力。 ## 9.5 外键设计方案比较 ### 方案一：逻辑外键为主 方案描述： - 主要依赖应用层维护对象引用关系，数据库中较少显式声明物理外键 优点： - 工程灵活性较高 - 部分演进场景下修改成本较低 缺点： - 参照完整性主要依赖应用层保证 - 不利于课程设计展示数据库完整性机制 - 不符合本次课程设计强调的数据库导向 ### 方案二：显式物理外键为主 方案描述： - 对核心关系建立明确的数据库物理外键，并说明删除策略 优点： - 参照完整性更明确 - 更符合数据库课程设计评价标准 - 更利于报告和答辩展示 缺点： - 在部分工程演进场景中灵活性较低 ### 选择结论 本课题采用方案二。对于平台基础、功能房预约和课程资源分享中的核心关系，优先采用显式物理外键。 ## 9.6 业务规则落点方案比较 ### 方案一：规则主要放在应用层 优点： - 编码灵活 - 初期实现较快 缺点： - 绕过应用层时数据库无法阻止非法数据写入 - 不利于体现数据库课程学习成果 ### 方案二：关键规则尽量数据库化 方案描述： - 对核心规则尽量通过主键、外键、唯一约束、检查约束、触发器等机制表达 - 应用层主要负责流程组织和友好提示 优点： - 更能体现数据库设计能力 - 一致性更强 - 便于答辩说明数据库的主动作用 缺点： - 设计和实现复杂度略有提升 ### 选择结论 本课题采用方案二。尤其在预约冲突、资源去重、状态一致性和积分幂等等方面，应尽量下沉到数据库层。 ## 9.7 组织层级建模方案比较 ### 方案一：仅使用父节点字段表示树结构 优点： - 建模简单 - 维护直观 缺点： - 查询“某部门及其全部子部门”时不够高效 - 数据范围控制与层级过滤实现复杂 ### 方案二：父节点字段配合闭包表 优点： - 既保留原始树结构，也便于进行后代查询 - 更适合“部门及子部门”这类课程设计中常见的数据范围需求 - 是较有展示价值的数据库建模方案 缺点： - 维护成本高于单表树 ### 选择结论 本课题倾向采用方案二。在平台基础模块中，组织层级应体现一定的数据库建模深度。 ## 9.8 功能房预约冲突控制方案比较 ### 方案一：仅在应用层查询判断冲突 优点： - 实现直接 - 对数据库对象要求较低 缺点： - 并发场景下容易依赖应用事务细节 - 不利于突出数据库约束能力 ### 方案二：数据库层约束配合应用层提示 优点： - 数据库能直接阻止非法时间重叠 - 更符合数据库课程设计对一致性的要求 - 有利于形成答辩亮点 缺点： - 设计复杂度较高 ### 选择结论 本课题目标是向方案二靠拢，使功能房预约成为数据库课程设计中的代表性业务案例。 ## 9.9 课程资源建模方案比较 ### 方案一：为查询便利保留大量冗余字段 优点： - 某些查询书写更方便 - 前期联表较少 缺点： - 容易引入冗余和一致性问题 - 在规范化说明中压力较大 ### 方案二：以规范化为基础，必要时保留受控冗余 优点： - 更符合 3NF 思路 - 更便于解释关系模式设计 - 后续如果保留冗余，也更容易论证其合理性 缺点： - 某些查询需要联表 ### 选择结论 本课题采用方案二。即：优先从规范化出发，只有在查询性能或业务语义确有必要时，才考虑保留受控冗余，并说明一致性保障机制。 ## 9.10 当前选型结论汇总 经过比较，本课题在需求分析阶段形成如下选型结论： - 题目范围： - 题目不变，聚焦主线模块 - 数据库口径： - 以 PostgreSQL 为核心数据库表达对象 - 运行环境口径： - 运行环境可以复用现有兼容平台，但报告与答辩以 PostgreSQL 为主语 - 认证策略： - 依托现有身份事实源，重点设计业务数据库 - 关系建模： - 核心关系优先使用显式物理外键 - 规则表达： - 关键业务规则尽量下沉到数据库层 - 组织结构： - 采用更适合层级范围判断的建模思路 - 资源建模： - 优先遵循规范化，再讨论必要冗余 这些选型共同体现了本课题的基本立场：优先满足数据库课程设计的规范性、完整性和可论证性。