我正在尝试为医师创建应用程序模型，并被困在数据库设计周围。假设用户可以创建一个案例，该案例可以与症状，诊断和疗法相关联。首先，这听起来并不难。
但是，我需要医生从给定的表格中提供诊断信息，该表格包括所有已知的诊断（由管理员播种）。此外，一种诊断可以有多种疗法，而医师应针对该特定病例选择一种疗法（同样，所有可能的疗法均由管理员植入）。
我还没有开始对应用程序进行编码，但是我已经创建了db diagram。到目前为止，我能想到的最好的方法是将cases和diagnoses关联到has_and_belongs_to。这似乎也不是最佳选择，因为一个病例只能进行一次诊断。
无论如何，我真的不太确定该如何处理therapies，因为只有has_one治疗和一种诊断可以has_many治疗。
我还考虑过使用jsonb列，但我宁愿坚持使用关系方法。
对此表示感谢！
答案 0 :(得分：1)
据我了解，您需要一个支持以下逻辑的模型：
如果这是正确的，那么到目前为止您所拥有的看起来还不错。一些评论/问题：
如果每个病例只能诊断一次，为什么不将diagnosis_id作为属性包含在cases表中？除非您需要专门跟踪案例-诊断关系之间的任何其他数据（您现在不执行此操作），否则不需要单独的表。这样可以减少额外的JOIN来加快查询速度。如果想一想，它可能会改变，那么您可以将其保留为单独的表格。
如果一个病例只能接受一种疗法，则可以再次将其作为属性包含在cases表中。参见＃1中的逻辑。
当您说诊断可以有多种疗法时，您是说用户将为诊断分配一种或多种疗法吗？如果是这样，只需创建一个名为case_diagnosis_therapy的新表即可在其中进行跟踪。病例的诊断与治疗之间的关系将通过(case_id, diagnosis_id)。您已经有了diagnoses查找表。
是的，我同意您更适合坚持使用关系设计而不是JSON。您的模型看起来很结构化。
只是约定的建议，当您创建表名时，通常使用单数名称-case而不是cases。
只需考虑几件事，否则看起来就不错了！希望有帮助。
答案 1 :(得分：0)
根据我的理解，是一个案例
diagnose_id（来自case_diagnoses表）唯一缺少的是therapies关联。我看到两个可能的选择：
例如对于发烧和脚踝扭伤，治疗方法都可以是“降温”，也可以是更具体的方法（以及更多与诊断有关的方法）。因此尚不清楚。
因此，如果疗法总是与单个诊断相关联：
如果一种疗法可以属于多个诊断，则只需添加一个中间链接表
...，其余部分保持不变。
（哦，谢谢您分享dbdiagram.io平台，我以前从未听说过，它看起来很棒！）