我有一个有趣的设计决定要在我计划最终发布的 Python Django 模型的上下文中做出。
这些类对 ApprovalRequest 进行建模，它表示用户提出的问题/请求，可以由另一个用户组投票，也可以上诉，然后可以由“更高级别”组再次投票，等等。
我有什么相当于以下模型树：
- ApprovalRequest（单个请求）
- 用户请求操作
- 行动类型* / 附加数据
- ApprovalStage（可能是多个投票阶段，按时间顺序排列）
- 相关的批准请求
- 投票类型（简单多数，需要一票等）
- 可以投票的用户*
- ApprovalVote（单票，由单个选民投票）
- 相关审批阶段
我的第一个问题与“动作类型”有关。因为我的意图是让它成为一个任何人都可以使用的可重用模块，所以我希望它在事件发生时发出信号。但是，此模型适用于许多事情 - 审核、用户提升、用户禁令上诉决定等。因此，需要某种“类型”参数。在 OOP 设计中解决此问题的经典方法是允许创建子类并具有自定义操作，这很好，但 Django（特别是）没有简单的方法从数据库中获取“正确”子类。例如，使用内置模型继承，将有一个主 ApprovalRequest db 表和 N 个附加 db 表，用于每个孩子的数据。
我最初的想法是创建一个子类“registry”，它会为我的类型字段分配一个唯一的 id，这样当我需要采取特定类型的操作时，我可以可靠地向下转换为注册类型。这将迫使子类为其子类选择一个（项目范围的）id，并且通常看起来不优雅。
我的第二个问题与“可以投票的用户”有关。我希望这些 ApprovalRequest 对象中的大多数实际上是由代码创建的，而不是通过例如 Django 管理员。假设发生以下动作：
- 用户请求促销（或其他操作）
- 创建 ApprovalRequest 对象，指定匹配某个代码相关组（即复杂查询集）的所有用户都可以投票
- 时间过去了，没有对 ApprovalRequest 采取任何行动
- 十个新用户现在满足复杂查询集的条件（也就是说，如果现在创建 ApprovalRequest，这些用户也将成为投票组的一部分）
- 我希望这些新用户能够投票
问题或多或少是，我如何以安全的方式存储这个复杂的查询集？我可以根据类型将这项工作委托给子类，但这似乎不优雅。我可以尝试以某种方式将查询集存储在数据库中，但这似乎有点 hacky。选择的标准路线是什么？
感谢您对这些问题的任何建议。