多人关系的Django方向

Question

我有两个简单的模型Article和Topic，正如您所猜测的那样，每一篇文章都可以属于一个或多个主题。在

这个小应用程序的主要功能是显示用户选择的特定主题的所有文章。在

什么样的车型应该有多人区？对于我的用例，我会说把它放在Topic模型中是有意义的。但是，如果我这样做，如果我添加一篇新文章，我总是需要2个查询（1个在Article模型上，1个在{}模型上，以建立关系）。在

我找到了这个generic rule，但在这种情况下它帮不了我什么忙。在

Answer 1

我会说你是自上而下做事的。哪个是顶层对象应该有关系描述（ManyToManyField）。在

为什么？从用户界面的角度看问题。在进入文章和主题之前，先展示主题或论坛的列表。restfulurl也遵循这一逻辑，因为url通常有TOPIC/TOPIC_id/post/post_id/而不是相反。基于这个原因，我认为有必要在主题中添加多个字段而不是帖子，添加到论坛而不是文章/线程。在

你还可以使用一些很酷的django工具，比如

Topic.objects.get(id = topic_id).select_related()

我的2分钱。在

编辑1

我不是一直遵循这个建议。例如：

有人就有群，这意味着要识别一群人。在哪里放很多个地方？Django，把很多人和他的人联系起来了(django.contrib.auth公司.models类用户通过mixin）而不是组。在一个案例中，我用另一种方式来做。为什么？因为我希望用户能够将Person添加到Group视图中，而不是Person视图中。我不想做一些事情，比如在一堆人中循环，给每个人添加一个组。回顾这一点，我仍然不知道这是一个坏的决定还是一个好的决定，因为这会给我带来任何问题：P

所以我想我想说的是，你应该分别评估每一个案例，并且总是提前考虑将来你想对每个类和对象做什么。在

/Edit1

Answer 2

“一般来说，在一个表单上要编辑的对象中应该有很多个域实例。在上面的例子中，toppings在Pizza（Article）中（而不是Topping（Topics）有一个pizzas（Article）ManyToManyField），因为认为一个Pizza（articles）上有toppings（Topics）比将Topping（topic）放在多个Pizza（articles）上更自然。按照上面的设置方式，Pizza（Article）表单允许用户选择配料（主题）

引用是因为有趣，doc的重点更多的是UI而不是ORM。在

而且你可能已经在这样做了，以防万一，我喜欢通过shell与我的应用程序交互，在这种情况下尝试不同的查询。在