【问题标题】:Many-to-Many Relationships in EF4 with "Shared" columnsEF4 中带有“共享”列的多对多关系
【发布时间】:2011-05-24 20:31:55
【问题描述】:

免责声明:严格来说,我在这里所拥有的不是多对多关系,但鉴于它使用的是关联表,我认为最好稍微降低准确性以便更好地了解我在做什么。

我的数据库中有以下三个表的等价物:

Customer
---------
CustomerID PK
...

CustomerAddress
---------
CustomerID PK, FK -> Customer
AddressNo  PK
... address columns ...

CustomerPrimaryAddress
--------------
CustomerID PK, FK -> Customer
AddressNo      FK -> CustomerAddress (with CustomerID, so CustomerID 
                                      participates in both relationships)

如果不是很明显,这里的目的是允许每位客户有多个地址,同时为每位客户指定最多一个地址作为“主要”地址。我使用关联表来避免在Customer 上放置一个可以为空的PrimaryAddressNumber 列,然后创建一个从CustomerCustomerAddress 的外键。

这一切都很好,但是 EF 然后将 CustomerPrimaryAddress 实体放在我的模型中。由于它的唯一目的是用作关联表,因此我无需在代码中表示此表。我从概念模型中删除了CustomerPrimaryAddress 表,然后在CustomerCustomerAddress 之间创建了一个关联,如下所示:

Table          Customer   CustomerAddress
Multiplicity   1          0..1

然后我将关联映射为使用存储模型中的CustomerPrimaryAddress 表,并且所有列都映射得很好,至少我是这么认为的。

我的问题是,现在 EF 抱怨 CustomerPrimaryAddress 中的 CustomerID 被映射到我的关联中的两个位置,因为它同时映射到 CustomerCustomerAddress

有没有办法解决这个问题?我不希望在Customer 中添加一个可以为空的列来表示主地址编号,因为从 DBA 的角度来看,这不仅不是一个令人愉快的选择,EF 还会抱怨存在周期性关系,我将不得不打破插入到代码中。

【问题讨论】:

    标签: entity-framework entity-framework-4


    【解决方案1】:

    在这里大声思考:

    Customer
    ---------
    CustomerID PK
    ...
    
    CustomerAddress
    ---------
    AddressNo  PK
    CustomerID FK -> Customer, non-nullable
    ... address columns ...
    
    CustomerPrimaryAddress
    --------------
    CustomerID PK, FK -> Customer
    AddressNo      FK -> CustomerAddress 
    

    似乎应该得到正确的基数,但我可能错过了一些东西。

    【讨论】:

    • 我想我明白你的意思了;在我的设计中,AddressNo 不会是CustomerAddress 中的唯一列(它在给定的CustomerId 中将是唯一的,从而形成复合主键)。我想我可以给CustomerAddress 一个单列标识键,并在CustomerAddress 上为两列创建一个(功能上无用,但FK 需要)唯一索引。
    • 在所有妥协中,这似乎是最理想的。虽然我更愿意将CustomerID 保留为CustomerAddress 的主键的一部分(它只是让我以错误的方式设计我的数据库以适应我的ORM),但这应该可以工作。如果没有其他奇迹出现,我会接受这个。谢谢!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-06-18
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多