如何处理Phoenix中的模式多态？

Question

在Phoenix中处理多态关联的推荐方法似乎是添加一个包含对其他模式的引用的中间模式:

• 与ecto反向多态
• https://hexdocs.pm/ecto/Ecto.Schema.html#belongs_to/3-polymorphic-associations).

所以,如果我想用不同种类的动物创建模式,我会这样做:

defmodule Animal do
  use Ecto.Model

  schema "animals" do
    belongs_to(:dog, Dog)
    belongs_to(:cat, Cat)
    belongs_to(:owner, PetOwner)
  end
end

defmodule Dog do
  use Ecto.Model

  schema "dogs" do
  end
end

defmodule Cat do
  use Ecto.Model

  schema "cats" do
  end
end

defmodule PetOwner do
  use Ecto.Model

  schema "pet_owners" do
    has_one(:pet, Animal)
  end
end

但我也可以使用PetOwner包含二进制字段和类型的模式:

defmodule Dog do
  use Ecto.Model

  schema "dogs" do
  end
end

defmodule Cat do
  use Ecto.Model

  schema "cats" do
  end
end

defmodule PetOwner do
  use Ecto.Model

  schema "pet_owners" do
    field(:pet, :binary)
    field(:pet_type, :integer)
  end
end

或者甚至只是对所有者模式中的所有动物都有一个可空的引用:

defmodule Dog do
  use Ecto.Model

  schema "dogs" do
    belongs_to(:owner, PetOwner)
  end
end

defmodule Cat do
  use Ecto.Model

  schema "cats" do
    belongs_to(:owner, PetOwner)
  end
end

defmodule PetOwner do
  use Ecto.Model

  schema "pet_owners" do
    has_one(:cat, Cat)
    has_one(:dog, Dog)
  end
end

第一种方法似乎增加了模式的复杂性.不同方法的优缺点是什么？

编辑:假设宠物主人只能拥有一只宠物,如果模式允许多只宠物,则在变更集中进行验证.

Answer 1

我花了很多时间阅读博客文章和类似问题的答案。我也在Elixir的论述中问了这个问题：https : //elixirforum.com/t/how-to-handle-schemas-polymorphism-in-phoenix/13269/24并收到了很好的答案。

可以肯定的是，该问题更多是SQL问题，而不是Phoenix或Ecto问题。确实，Ecto提供了一些解决此问题的方法，但该问题的解决应以“如何处理关系数据库中的多态关联”开头。

请注意，如果您在这里寻找解决“ belong_to”多态关联的解决方案（也就是说，如果一个具体表属于两个或多个多态表），那么Ecto的文档中将有一整节内容。这个答案是针对“ has_many”多态关联的。

这是ndac_todoroki在回答我在Elixir论坛上发布的文章时所使用的不同方法的比较，所有功劳归功于他：

单表继承

这是当您有一张大桌子（动物）并且每个具体的动物桌子都是该桌子的细分时。您不会有多个表。

优点

• 您只有一张桌子。
• 取回所有动物非常容易
• 它可以在Ecto中轻松实现，因为所有具体的动物模块可以具有彼此不同但引用同一张大表的架构。

缺点

• 如果您想要每种动物的唯一字段，那么您到处都会得到NULL列（但是您不在乎使用具体模块的模式：它不会出现。）

类表继承

这是当您有一个基表（= Animal），并且每个具体的动物表都有对基表及其唯一字段的引用。（动物{id：1，出生：“ 20180101”，已接种疫苗：是}动物{id：2，出生：“ 20111225”，已接种疫苗：假/猫{animal_id：1，颜色：“棕色”} Snake {animal_id：2 ，长度：150}）

优点

• 如果只需要基本信息，列出所有动物都非常容易
• 没有NULL列

缺点

• 从具体模块获取（动物的）全部信息非常容易（您只需JOIN：animal），而从基础侧获取全部信息却不容易（您不知道要加入什么）。
• 除非您编写类似于Rails中的多态表的逻辑（animal_type和animal_id），否则在Ecto文档中将其称为“不推荐”。

具体表继承

不会创建动物表格。每个具体的动物表将具有所有基本信息及其唯一信息。如果您想确保所有动物都是动物，那么这会很好，但是您不直接与动物一起工作。（我宁愿创建一个名为Animal的协议，而不是这样做）

优点

• 取出混凝土动物时无需加入
• 与Ecto的抽象表配合使用（动物将是抽象表）

缺点

• 您需要谨慎进行迁移，以免破坏整个继承
• 唯一断言必须完全在应用程序逻辑上完成
• 特别是id在所有动物表中必须是唯一的，因此最好使用：binary_ids。
• 使用Animal中的键进行的任何搜索都应遍历所有表（ugh）

摘要表

Ecto文档中对此进行了描述。（示例回购）仅使用此功能似乎对您的用法没有太大帮助，但是如果您正在查看STI或CTI，则可能对实现有所帮助。

创建类表继承时，每个表都引用一个动物基表。使用抽象表，您可以针对每个具体的动物表将其拆分为多个基本表，例如，猫表将cat_base和snake引用为snake_base，其中cat_base和snake_base将具有相同的列。然后，我们将创建一个抽象的表格动物，当您| | Animal.add_base_animal_info（）时，它将创建一个cat_base。

优点

• 您可以从动物取回具体动物

缺点

• 您需要加入每个具体的* _base表来执行list_animals

我认为这介于类表继承和具体表继承之间。

嵌入数据

可以在Postgres和MongoDB等中进行嵌入。您可以有一个动物表，该表具有一个接受地图的字段（field：details，：map）。然后，您定义许多具体的动物模块，它们的架构引用该动物表，具有embeds_one：details，CatDetails，在其中为CatDetails定义embed_schema。（此示例是带有嵌入的STI）

优点

• 桌子会很干净
• 没有NULL
• 列出所有动物很容易
• 使用具体动物的模式存储数据将验证您通过的地图的形状

缺点

• ：details内部的地图形状无法在数据库级别验证
• 搜索嵌入中的字段可能不好（取决于您使用的数据库）