0

我有Users哪个可以是TypeS, TypeC, 或TypeA. 我有每种类型的模型来存储附加信息。现在，在Users桌子上，我应该有

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

如果您想提供更精致的答案，我正在使用 Django。

4

3 回答 3

4

Django 提供通用关系作为内容类型框架的一部分，它允许您实现类似于您的选项#2 的东西，只是更灵活。您可以通过将以下字段添加到模型来建立通用关系：

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

这样，您可以将TypeS、TypeC或中的一个分配给有TypeA问题的每个用户。此外，如果您需要添加 aTypeX或 a TypeY，您已经设置好并且不需要扩展模型。

于 2010-02-13T22:13:50.483 回答
1

我自己也遇到过几次这种情况。我个人的偏好是选项 1（除非有 20 种类型的用户）。

  • 选项 1 使您可以选择进行外键引用，从而保证数据库完整性（对三列有约束）。

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

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

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

于 2010-02-13T21:46:43.530 回答
1

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

  • 最简单、最快速的额外信息查找
  • 浪费的磁盘空间是最小的
  • 确定它是哪种类型的编程逻辑并不复杂（尽管比如果你有“双字段”的可能性稍微复杂一些。）

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

编辑：考虑选项 #2 的原因之一......如果您预计类型的数量可能从 3 增加到 10 或 100，选项 #1 系统将变得越来越烦人..

于 2010-02-13T21:48:35.087 回答