我想实现一个通用表格， info ，列类型和 foreign_id 。 foreign_id 是根据类型的不同表的外键。
使用Doctrine ORM，我的理解是你需要提前指定映射关系。但是，由于 foreign_id 可以根据类型链接到不同的表。你如何使用ORM实现这种关系？
目前，我通过创建多个表来解决这个问题，例如 info_a ， info_b ， a_id 和 b_id 。如果类型的数量增加，它将导致许多表具有基本相似的结构。
如何使用ORM解决此问题？提前谢谢。
答案 0 :(得分：2)
你＆＃34;解决＆＃34;这可以通过接受这个将具有多个表格＆＃34;具有类似结构＆＃34;
的事实。您拥有表格的原因是不他们的结构，您拥有表格的原因是他们（及其内容）对最终用户意味着什么
因此，关于应该具有多少个表的决定应首先由它们对用户表示的含义驱动，具有不同类型的含义导致不同的表。观察两张桌子＆＃34;具有相同结构的习惯＆＃34;因此应该合并为一个很普遍，但它仍然是一个严重的错误。
帮自己一个忙，学习/采用＃34;泛型表＆＃34;很糟糕。
答案 1 :(得分：0)
您没有多个外键。你有让人想起FK的东西。 FK是一个列集，其子类型值始终也在另一个表中，其中列构成候选键。评论说你的设计是反模式的，因为它是不必要的复杂。 SQL不容易支持其完整性或优化。
而不是在表信息中使用列类型和foreign_id [sic]，其中类型值指示它必须作为id值出现在哪个其他表中，对于具有FK foreign_id的类型中允许的每个值，可以直接获得表VALUE_info到适当的VALUE_other表id。
然而，您可能真正需要的是每个VALUE_other表，以使其foreign_id列成为FK引用信息。也就是说你可能希望FK走另一条路。当info（id，type，...）表示“thing [id]是子类型[type]和...）而VALUE_other（foreign_id，...）表示”thing [foreign_id]属于子类型VALUE并且...“。请注意，正确的名称是thing_info（id，type，...）和VALUE_thing_info（id，...）。您可能不再需要类型。类似的东西可能都会自动设置由一个明确支持“subtyping”或“polymorphism”的ORM。
如果这符合您的需要，那么在这种特殊的子类型情况下，因为您能够将每行信息都有一个foreign_id FK到一个VALUE_other表，这意味着每件事都只有一个子类型。对于最多一个子类型，您可以为每个VALUE_thing_info表编写一个SQL约束，即thing_info中id的匹配行的类型值为VALUE。 （技术上类型在数据库中仍然是冗余的，但它可以帮助提高清晰度和效率。）您可以编写一个SQL约束，即thing_info id值在VALUE_thing_info id值的并集中。 （一些这样的约束可以是声明性的。在thing_info中输入类型也有帮助。在VALUE_thing_info表中放置类型是另一个更冗余的习惯用法，但也可以帮助更多声明。虽然对更新的约束可以更快。）