坚韧的继承数据库/模型设计决定

我有Users它可以是TypeS,TypeC或TypeA。我有每种类型的模型来存储附加信息。现在，在Users表，我应该有坚韧的继承数据库/模型设计决定

3空的外键字段指定他们是
2场，1与类型的名称和1与外键
哪种类型1字段指定与其他型号的外键类型
用户没有字段，并依靠检查反向关系？

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

2010-02-13 mpen

Django提供Generic relations作为contenttypes framework的一部分，它允许您实现类似于＃2选项的功能，而且更加灵活。您可以通过添加以下字段到模型建立通用的关系：

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

这样你就可以分配的TypeS一个，TypeC，或TypeA到每个所讨论的用户。另外，如果您需要添加TypeX或TypeY，则您已经设置好了，不需要扩展模型。

来源

2010-02-13 22:13:50 flanth

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

选项1为您提供了用于保证数据库完整性（对三列有约束）的外键引用的选项。
选项2这不是实际的外键引用。该记录可能不再存在于类型表中。表连接是不可能的。
选项3甚至比选项2更差，在导航到类型表之前需要解释该值。
选项4可能，但它有点像寻找你的类型数据。它将允许一个用户拥有多个类型定义。

来源

2010-02-13 21:46:43 Zyphrax

等等...是4真的很差？难道你不能一次性将所有3种类型连接起来，然后如果数据在那里，它就在那里，如果没有，它不是？ – mpen 2010-02-14 23:07:41

和＃3 ...我将不得不检查他是什么类型的用户。如果没有首先检查他是否是TypeC，我不能只开始访问TypeC数据。其实......我猜想那需要两个查询，而不是一个？但即使是1，在我开始加入东西之前，我必须检查FK是不是空的？ – mpen 2010-02-14 23:11:28

我会使用选项＃1,3可空的外键。它允许您使用实际的数据库外键关系，其中选项＃2，＃3和＃4不会。因此，你会得到：

最方便快捷的查找了额外的信息
浪费的磁盘空间最小
编程逻辑来确定哪些类型，它并不复杂（虽然稍更复杂的比起来，如果你有一个“二场”的可能性。）

至于你的问题的第2部分，我想我有一个空的外键到另一个表来保存业务特定领域。

编辑：有一个原因考虑选项＃2 ...如果您预期可能的类型数量可能会从3增加到10或100，则选项＃1系统将变得越来越讨厌..

来源

2010-02-13 21:48:35

坚韧的继承数据库/模型设计决定

回答

相关问题