如何在不插入空行的前提下获取Room自增主键以创建关联实体

问题1：数据库实体类是否可以直接作为全局业务类使用，是否需要拆分 #

• 没有强制的对错标准，完全根据项目规模和迭代需求判断：
  • 如果你做的是小型个人项目、当前两者字段完全一致、后续需求变动概率极低，直接复用完全可行，不需要做无意义的字段映射增加开发成本。如果选择复用，所有非表结构的自定义字段、方法都要加@Ignore注解，避免Room编译时报错。
  • 如果是中大型团队协作项目、后续有明确的迭代规划，哪怕当前字段完全一致也建议拆分：
    • 数据库实体的变更受表结构严格约束，随意修改会导致数据迁移异常，拆分后业务类可以灵活适配UI、逻辑层的需求，不会影响存储层稳定性
    • 避免@Entity、@ForeignKey这类数据库专属注解泄漏到上层业务，后续如果要更换存储方案不需要修改上层业务代码
    • 业务类可以按需添加计算字段、工具方法，不会污染数据库实体的表结构定义

问题2：是否需要先插入空的Entity A记录获取自增主键再构建关联实体 #

• 不推荐插入空记录的方案，会产生大量无效脏数据，如果用户点击添加后中途取消操作，空的Entity A记录会残留在库中，后续还要额外做清理逻辑，增加不必要的复杂度。
• 推荐两种更合理的解决方案：
  1. 先收集完所有需要提交的用户输入（包含Entity A和所有关联实体的内容），在同一个事务中执行插入：先插入Entity A，@Insert注解修饰的方法插入带自增主键的实体时，会直接返回生成的主键值，拿到主键后再赋值给关联实体的外键字段，最后一次性插入所有关联实体即可。
  2. 如果业务逻辑要求用户先填写Entity A内容、再跳转到多个子页面填写关联实体内容，可以给Entity A增加一个is_draft的布尔类型标记字段，用户最终确认提交前所有数据都标记为草稿状态，用户取消操作或退出页面时统一清理所有草稿数据即可，比完全空的记录更容易维护。

额外实践建议 #

• 所有涉及外键关联的写操作一律用@Transaction注解包裹，避免出现Entity A插入成功但关联实体插入失败的数据不一致问题
• 关联实体的复合主键包含外键时，建议提前在DAO层封装好联合查询方法，避免业务层手动拼接查询条件出错
• 如果后续有跨设备数据同步的需求，不要用自增主键作为全局唯一标识，可以额外加一个字符串类型的UUID字段做同步标识

内容的提问来源于stack exchange，提问作者Omar Shawky