1

我试图找到一种合适的模式来模拟从几个表到一个公用表的一对多关系。

EntityA、EntityB等实体有一个或多个GenericInfo。

  • EntityA (0..1) ------ (1..N) GenericInfo
  • EntityB (0..1) ------ (1..N) GenericInfo
  • EntityC (0..1) ------ (1..N) GenericInfo

    选项1：这些实体是不同的，所以我不能使用超级表来模拟关系，比如

  • 超级实体 (S_Id pk)
  • EntityA (S_Id pk fk)
  • 实体 B (S_Id pk fk)
  • GenericInfo (G_Id pk, S_id fk)


    选项 2：我不想通过从 GenericInfo 表中删除外键约束来失去参照完整性。

  • EntityA (S_Id pk fk)
  • 实体 B (S_Id pk fk)
  • GenericInfo（G_Id pk，unique_id 非 fk）


    选项3：我目前正在使用关联表进行关系映射。

  • 实体A (A_Id pk)
  • 实体 B (B_Id pk)
  • EntityAInfo(A_Id pk fk, G_Id pk fk)
  • EntityBInfo(B_Id pk fk, G_Id pk fk)
  • GenericInfo (G_Id pk)

    我不喜欢这个解决方案，因为必须在数据库中创建太多表，其全部目的是保留链接/关系。

    选项4：我能想到的另一种方法是创建一个像这样具有单个 Id 属性的映射表，

  • EntityA（A_Id pk，I_id fk 可为空）
  • EntityB（B_Id pk，I_id fk 可为空）
  • 信息映射（I_Id pk）
  • GenericInfo (G_Id pk, I_Id fk)

    我喜欢您的专家意见和意见。

    谢谢，

    更新

    瓦塞克，感谢您的评论。

    我试图解决的问题是：如何为公开对象集合的接口实现建立对象关系映射？

    我们为 OR 映射使用每个类策略一个表。因此，示例中的每个表都是从一个类映射的。假设我们有以下类型定义和表格（很遗憾我不能在这里发布图表）


    公共接口 IGenericInfoProvider
    {
    GenericInfo [ ] GenericInfoArray {get;set;}
    }


    公共类 BaseClassForA {} ---------------------------------------------表 BaseEntityForA
    公共类 BaseClassForB {} ------------------------------------------- -- 表 BaseEntityForB
    公共类 ClassA : BaseClassForA, IGenericInfoProvider {} --- 表 EntityA
    公共类 ClassB : BaseClassForB, IGenericInfoProvider {} --- 表 EntityB
    公共类 GenericInfo {} ------------- --------------------------------------- 表 GenericInfo

    我正在尝试对 EntityA/EntityB 和 GenericInfo 之间的一对多关系进行建模。这种关系在我们的领域模型中很常见。
    Option1不被​​考虑，因为这会导致创建一个超级表来包含许多表中的所有 id，并且它在 OO 世界中没有任何意义。 由于参照完整性，选项 2 是不可接受的
    。
    Option3是我目前使用的模式。
    我正在考虑Option4，但不确定它是否是正确方向的方法。

    • 4

    2 回答 2

    1

    我不确定您希望实现什么，但我想尝试使用一些数据库设计工具来创建包含表、主/外/备用键、复合键、关系等的结构可能会很有用。一张图片值得一看千言万语：）你可以快速创建各种设计，生成 SQL 代码并考虑如何存储示例数据。

    对我来说，第一个场景（选项 3）似乎代表了 M:N 关系。第二种情况（选项 4）代表不同的情况 - 不同的参照完整性，因此这两种情况不具有可比性。

    尝试创建示例数据库、插入示例记录并编写查询。

    于 2012-06-15T13:42:18.597 回答
    0

    您当前的解决方案是正确的解决方案。这是保持数据完整性的最佳方式，这是数据库最关键的功能。制作更多的桌子甚至不应该成为设计考虑因素。

    于 2012-06-15T17:50:04.193 回答