【问题标题】:How to handle "secondary" keys in Entity Framework如何处理实体框架中的“辅助”键
【发布时间】:2010-10-12 21:06:21
【问题描述】:

我正在针对现有架构使用 EF 进行评估 - 问题是我无法弄清楚如何在外键不是主表的主键的表之间建立关联。

例如,foo 可能有多个 bars 定义如下(请原谅伪代码):

table foo {
  int foo\_id pk,
  char(10) foo\_code,
  ...
}

table foobar {
  int bar\_id pk,
  char(10) bar\_foo\_code fk(foo.foo\_code),
  ...
}

我缺少什么能够创建foo_foobar 关联,从而在Foo 实体上创建Bars 导航属性?

【问题讨论】:

  • 我们在这里遇到了同样的问题,最后不得不对我们的数据库进行更改,以便外键只指向主键。有没有办法改变你的数据库架构?
  • 不幸的是,由于遗留原因,架构是一场噩梦,我们必须与它进行互操作。糟透了,我知道。话虽如此,我已经看到同时拥有主键和单独(可能是复合)外键的情况是完全正确的。

标签: entity-framework mapping foreign-keys


【解决方案1】:

Linq to entity 不支持不指向表主键的外键(请参阅日志消息 3)。 Linq to entity 会将其视为表上的普通字段。您将无法导航到它所链接的实体。

如果您有现有架构,我建议您使用edm generator,因为这将创建 EMDX 文件、隐藏代码甚至视图代码(可能非常大)。如果您现有的方案非常大,请查看此post,它解释了如何处理大型模式。

当您运行 EDM 生成器时,您会发现所有不受支持的内容。

查看之前的 EDMGen2.exe 日志,我们得到了以下类型的消息:

  1. 数据类型“sql_variant”不是
    支持,列 'ColumnName' 在表 'TableName' 中是 排除在外。
  2. 表/视图“tableName”不 有一个主键定义。钥匙 已推断和定义 被创建为只读表/视图
  3. 关系“RelationshipName” 有不属于的列 桌子上的钥匙 关系的主要方面 这是不支持的, 关系被排除在外。

我们还发现 Linq 项目实际上使 Visual Studio 崩溃了很多,因为 EDM 生成的代码文件超过 80 mb。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2011-01-18
    • 1970-01-01
    • 2014-08-22
    • 1970-01-01
    • 1970-01-01
    • 2011-04-13
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多