艰难的继承数据库/模型设计决策

Question

我有Users ，其可以是TypeS ， TypeC ，或者TypeA 。 对于每种类型，我都有用于存储其他信息的模型。 现在，在“ Users表中，我应该

1. 3个可为空的外键字段，以指定它们是哪种类型
2. 2个字段，1个带有类型名称，1个带有外键
3. 1个字段用其他模型上的外键指定类型
4. 用户上没有字段，并依靠检查反向关系吗？

如果您想提供更精致的答案，则使用的是Django。

Answer 1

Django将通用关系作为contenttypes框架的一部分提供，它使您可以实现与选项＃2类似的方式，只是更加灵活。 您可以通过在模型中添加以下字段来建立通用关系：

content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
content_object = generic.GenericForeignKey('content_type', 'object_id')

这样，您可以将TypeS ， TypeC或TypeA之一分配给每个有问题的用户。 另外，如果您需要添加TypeX或TypeY ，则已经设置好了，不需要扩展模型。

Answer 2

我本人几次遇到这种情况。 我个人的喜好是选项1（除非会有20种类型的用户）。

• 选项1为您提供了进行外键引用的选项，以保证数据库的完整性（在三列上都有一个约束）。

• 选项2，这不是实际的外键引用。 该记录可能不再存在于“类型”表中。 表联接是不可能的。

• 选项3甚至比选项2差，在导航到类型表之前需要先解释该值。

• 选项4是可能的，但是有点像寻找类型数据。 它将允许一个用户具有多个类型定义。

Answer 3

我将使用选项＃1，3个可为空的外键。 它允许您使用实际的数据库外键关系，而选项＃2，＃3和＃4则不会。 因此，您将获得：

• 最简单，最快的查询以获取更多信息
• 浪费的磁盘空间很小
• 用于确定哪种类型的编程逻辑并不复杂（尽管比可能具有“两字段”的情况要复杂得多）。

就您的问题的第2部分而言，我想我要向另一个表使用一个可为空的外键来保存特定于业务的字段。

编辑：有一个理由来考虑选项＃2 ...如果您期望类型的数量可能会从3增加到10或100，选项＃1系统将变得越来越烦人。