Django / Wagtail 中的大型嵌套层次结构：育儿还是分类？

Question

我有一个数据库，其中包含 50,000 种药物（药物）的元数据，这些元数据按层次结构排序（分类法称为 ATC）。心脏药物的例子如下：A-- A10---- A10X、美托洛尔有些药物有 4 个级别。我需要为每种药物生成一个单独的页面。在 wagtail/django 中执行此操作最有效的方法是什么，包括考虑到用户需要一种简单直观的方式来搜索数据库。我尝试过django-mptt，定义以下模型。class ATCChapter(MPTTModel): # MAIN CHAPTER    chapter_letter = models.CharField(max_length=255, null=True, blank=True) # E.g "A"    chapter_title = models.CharField(max_length=255, null=True, blank=True) # E.g "Cardiac drugs"    parent = TreeForeignKey('self', on_delete=models.CASCADE, null=True, blank=True, related_name='children')    class MPTTMeta:        order_insertion_by = ['chapter_letter']class ATCSubchapter(MPTTModel): # SUBCHAPTER    subchapter_letter = models.CharField(max_length=255, null=True, blank=True) # E.g "A10"    subchapter_title = models.CharField(max_length=255, null=True, blank=True) # E.g "Drugs used in heart failure"    parent = TreeForeignKey(ATCChapter, on_delete=models.CASCADE, null=True, blank=True, related_name='subchapter')    class MPTTMeta:        order_insertion_by = ['subchapter_letter']class ATCDrug(MPTTModel, Page): # INDIVIDUAL DRUG    drug_code = models.CharField(max_length=255, null=True, blank=True) # E.g "A10X"    drug_name = models.CharField(max_length=255, null=True, blank=True) # E.g "Metoprolol"    parent = TreeForeignKey(ATCSubchapter, on_delete=models.CASCADE, null=True, blank=True, related_name='disease')    class MPTTMeta:        order_insertion_by = ['drug_code']进行迁移会引发以下错误：class ATCDrug(MPTTModel, Page): TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases这可以通过不让该类继承 Page 来解决，这当然是不好的。我删除了Page并尝试了模型，但无法验证父子方案是否正确。问题：考虑到目标，我是否做了一些明显错误或次优的事情。系统：Wagtail 2.10，Postgresql，计划使用Algolia进行搜索。感谢您的任何建议。

Answer 1

根据您对每种药物都用一个页面表示的要求，并且如果您确实打算在中长期使用 Wagtail，我建议每种药物都是页面模型。

这是因为您将获得能够向用户展示这一点、提供搜索、API 和 UI 编辑功能而没有任何麻烦的所有好处。

然而，下一个决定涉及是否将所有这些都放在一个父页面模型下，或者还将层次结构存储在页面模型中。

如果您知道层次结构在五个深度级别上将非常严格，并且每个深度都有特定的名称和商定的定义，那么最好将这些“级别”也编码到模型中。请注意，每个药物页面的 url 将默认为url.com/level-1/level2-/..../insulin而不是类似url.com/medications/insulin.

然而，通过RoutablePageMixin也可以很容易地使每种药物在 Url 树中的某个固定（非嵌套）点可用。然而，如果您希望规范 URL 是这种非嵌套变体，您可能会发现自己与 Wagtail 进行了少量的斗争。这样做的好处是，您只需通过内置的页面浏览器（管理菜单）导航，就可以在树的正确位置找到胰岛素页面。

换句话说，仍然可能值得将层次结构存储为页面模型，但药物页面模型本身将是其他某个中心页面的子级。这为您提供了每种药物的更简单的规范 URL，但也意味着每个级别的页面都可以使用 RoutablePageMixin 来授予对其后代子代的访问权限。这种方法的缺点是管理编辑界面不会直接反映药物页面的层次结构。

然而，在有 50,000 个条目时，编辑交互将需要一些调整和替代方法来查找页面。

例如

• 家

• ... 级别

• ...... A1（等）

• ...药物

• ...... 胰岛素

• 联系方式（其他杂项页面也将在主页下）

这里可能没有“正确”的答案，您可能会发现最好设置一些页面和链接的编程创建（或类似于固定装置的东西），然后两种方式都做，并在您的 Beta Wagtail 实例中设置两个站点。通过这种方式，您可以了解编辑的感觉，让您的团队有机会参与并设置 API。最后，无论哪种方式，您最终都需要在页面模板和模型方面非常相似的代码。