elixir - 如何在Phoenix中处理模式多态性？

Question

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


Inverse polymorphic with 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的文档中对此有一个entire section。该答案针对“ 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内部的地图形状无法在数据库级别验证
搜索嵌入中的字段可能不好（取决于您使用的数据库）