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

时间:2010-02-13 21:33:04

标签: database django models design-decisions

我有Users,可以是TypeSTypeCTypeA。我有每种类型的模型来存储其他信息。现在,在Users表中,我应该

  1. 3个可空的外键字段,用于指定它们的类型
  2. 2个字段,1表示类型名称,1表示外键
  3. 1字段用另一个模型上的外键指定类型
  4. 用户没有字段,并依赖检查反向关系?
  5. 如果你想提供更精确的答案,我正在使用Django。

3 个答案:

答案 0 :(得分:4)

Django提供Generic relations作为contenttypes framework的一部分,它允许您实现类似于您的选项#2的东西,更灵活。您可以通过向模型添加以下字段来建立通用关系:

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

通过这种方式,您可以为每个有问题的用户分配TypeSTypeCTypeA之一。此外,如果您需要添加TypeXTypeY,您已经设置好了,不需要扩展模型。

答案 1 :(得分:1)

我自己曾经遇到过这种情况。我个人的偏好是选项1(除非有20种类型的用户)。

  • 选项1为您提供了外键引用的选项,以保证数据库的完整性(对三列有约束)。

  • 选项2这不是实际的外键引用。 Type-table中不再存在该记录。表联接是不可能的。

  • 选项3甚至比选项2更差,需要在导航到Type-table之前解释该值。

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

答案 2 :(得分:1)

我会使用选项#1,3可空外键。它允许您使用实际的数据库外键关系,选项#2,#3和#4不会。因为你会得到:

  • 最简单,最快速的查询额外信息
  • 浪费的磁盘空间很小
  • 用于确定其类型的编程逻辑并不复杂(尽管比具有“双字段”可能性的情况稍微复杂一些。)

至于你问题的第2部分,我认为我有一个可以为另一个表保存特定业务字段的可以为空的外键。

编辑:有一个理由考虑选项#2 ......如果您预计类型数量可能会从3增加到10或100,那么选项#1系统将变得越来越烦人..