设计一个存储专利审查数据的数据库，请说明数据库选型（关系型或非关系型）、表结构设计（如案件表、审查员表、审查意见表等）及索引策略。

1) 【一句话结论】采用关系型数据库（如MySQL/PostgreSQL），因其支持复杂事务、数据完整性约束，适合专利审查中结构化、强关联的业务场景。

2) 【原理/概念讲解】老师讲解关系型数据库（RDBMS）与非关系型数据库（NoSQL）的核心差异。关系型数据库基于关系模型，用表（表结构：列+行）存储数据，通过主键外键维护表间关系，支持ACID事务（原子性、一致性、隔离性、持久性），适合结构化数据（如专利案件信息、审查员信息）的严格管理。类比：就像图书馆的“书目表”（书号、书名、作者、馆藏位置），通过书号关联“借阅记录表”，能精准查询某本书的借阅历史，且借阅操作（增删改）能保证数据一致性。非关系型数据库则更灵活，如文档型数据库（MongoDB）用JSON文档存储，适合数据结构多变（如审查意见的补充说明）的场景，但牺牲了事务一致性。

3) 【对比与适用场景】

特性/类型	关系型数据库（如MySQL）	非关系型数据库（如MongoDB）
定义	基于关系模型，表结构固定，数据以行/列为单位	无固定模式，数据以文档/键值/列族/图为单位
关系处理	强关系，通过外键关联表	弱关系或无关系
事务支持	强事务（ACID），适合复杂业务	弱事务或无事务（如Redis支持事务，但有限）
扩展性	垂直扩展（提升服务器性能）	水平扩展（增加节点）
适用场景	结构化数据，强一致性要求（如专利案件状态变更）	非结构化/半结构化数据，高并发读写（如临时审查意见草稿）
注意点	表结构变更复杂，不适合频繁变更	数据一致性需自行保证，不适合强事务场景

4) 【示例】表结构设计（以MySQL为例）：

• 案件表（case）：案件ID（主键，INT AUTO_INCREMENT）、申请号（VARCHAR, 唯一）、申请日（DATE）、当前状态（状态ID, INT, 外键）、提交人（审查员ID, INT, 外键）。
• 审查员表（reviewer）：审查员ID（主键, INT）、姓名（VARCHAR）、专业领域（VARCHAR）、登录账号（VARCHAR）。
• 审查意见表（review_opinion）：意见ID（主键, INT）、案件ID（INT, 外键）、审查员ID（INT, 外键）、意见内容（TEXT）、提交时间（DATETIME）。
• 状态表（status）：状态ID（主键, INT）、状态名称（VARCHAR）、描述（VARCHAR）。
  索引策略：案件表的主键（案件ID）、申请号（唯一索引）；审查员表的姓名（普通索引）；审查意见表的案件ID（外键索引）、审查员ID（外键索引）、提交时间（普通索引）。

5) 【面试口播版答案】面试官您好，针对专利审查数据存储，我建议采用关系型数据库（如MySQL或PostgreSQL）。原因在于专利审查数据具有强结构化、多表关联（如案件-审查员-意见）和事务一致性要求（如状态变更需原子操作）。具体设计上，核心表包括案件表（存储申请号、申请日、状态等）、审查员表（存储审查员信息）、审查意见表（存储具体意见内容）。索引方面，对高频查询字段（如申请号、审查员ID）建立主键/外键索引，对时间字段（提交时间）建立普通索引，提升查询效率。这样既能保证数据完整性，又能高效支持审查流程的查询与更新操作。

6) 【追问清单】

• 问：如果数据量增长到百万级，如何优化索引或表结构？答：可通过分库分表（如按申请号范围分表）、建立复合索引（如申请号+提交时间）优化查询，或使用读写分离提升性能。
• 问：非关系型数据库（如MongoDB）是否适合？答：若审查意见包含大量非结构化补充说明（如图片、附件），可考虑MongoDB存储，但需自行保证数据一致性，不适合核心业务的事务场景。
• 问：事务处理中，如何保证审查意见提交后案件状态同步？答：通过事务（BEGIN TRANSACTION...COMMIT）确保“提交意见”与“更新案件状态”原子执行，避免数据不一致。

7) 【常见坑/雷区】

• 忽略事务一致性：如仅用非关系型数据库存储审查意见，未保证意见提交后案件状态同步，导致数据不一致。
• 表结构设计冗余：如案件表中重复存储审查员信息，增加存储开销且影响更新效率。
• 索引选择不当：如未对申请号（唯一标识）建立索引，导致查询效率低。
• 非关系型数据库适用场景误判：如将结构化数据（如案件信息）存入MongoDB，导致查询复杂且性能下降。