c# - 使用 Entity Framework Code First 将 SQL 表主键定义为区分大小写

Question

是否可以先在 Entity Framework 代码中定义区分大小写的 SQL 主键？我知道默认情况下，SQL 在涉及字符串时不区分大小写，只是为了清楚起见，我不想将整个数据库定义更改为区分大小写，只是一个表列(主键)。

我从外部 API 获取数据，该 API 使用区分大小写的主键发送数据('a' 和 'A' 是不同的记录)，我知道我可以修改它们并将它们以不同的方式保存在我的数据库中，但是这还将要求我在我的代码中的任何地方都保持一致。这绝对是可能的，但我宁愿避免它。

理想情况下，我希望找到一种方法来通过 Entity Framework 将我的主键定义为区分大小写，而不是使用 SQL queries .

我将不胜感激任何建议，或者更好的是一种简单的方法。

更新

好的，所以我已经对这成为可能失去了希望，现在当我尝试使用另一种方法时:

public ovveride Up()
{
  // drops the existing primary key named PK_dbo.Urls
  Sql("ALTER TABLE dbo.Urls DROP CONSTRAINT [PK_dbo.Urls]");

  // change the collation
  Sql("ALTER TABLE dbo.Urls ALTER COLUMN Url VARCHAR(10) COLLATE SQL_Latin1_General_CP1_CS_AS NOT NULL");

  // re-add the primary key to the Url column
  Sql("ALTER TABLE dbo.Urls ADD CONSTRAINT [PK_dbo.ShortUrls] PRIMARY KEY (Url)");
}

我真的无法完成它，因为我在这个字段上有 4 个不同的约束(主键 + 3 个其他)。

我不想自己重写约束代码。那么我可以使用 Fluent API 来进行区分大小写的更改吗？

这是自动生成的 Fluent API 代码:

CreateTable(
                "dbo.Shapes",
                c => new
                    {
                        TabID = c.Int(nullable: false),
                        Lbl = c.String(nullable: false, maxLength: 128),
                        wasRemoved = c.Boolean(nullable: false),
                    })
                .PrimaryKey(t => new { t.TabID, t.Lbl })
                .ForeignKey("dbo.Tabs", t => t.TabID, cascadeDelete: true)
                .Index(t => t.TabID);

我真的很感激一个解决方案，因为我已经坚持了一段时间，现在我正在寻找最好的最坏的解决方案。

更新 2

我还找到了第二种方法，它是全自动的，在你定义了很多其他东西之后，无论如何它使用自定义数据注释。有关详细信息，请参阅下面的答案。

Answer 1

到目前为止，我得到的最好的解决方案(我认为它绝不是一个好的解决方案)是使用 EF 生成 sql 脚本，然后在那里进行修改。

我这样做的原因是因为我要更改的值不仅是一个主键，它还涉及其他 3 个约束。

如果其他人遇到同样的情况并且只需要解决方法，您可以执行以下操作:

保存sql脚本到一个新的查询:

Update-Database -Script -SourceMigration:0

然后不要删除和添加许多约束，只需找到定义您希望区分大小写的主键的行，在我的例子中:

[Lbl] [nvarchar](128) NOT NULL

更改为:

[Lbl] [nvarchar](128) COLLATE SQL_Latin1_General_CP1_CS_AS NOT NULL

在您运行脚本之前，确保在其他表中将其用作外键时添加 COLLATE SQL_Latin1_General_CP1_CS_AS。

我不喜欢这个解决方案，但我只是在使用它，因为它是我的全部。如果您有更好的解决方案，请发布!

方案二

我可以确认this也有效，这有点过头了。你定义你自己的数据注解，这里我们定义一个自定义的[CaseSensitive]。工作得很好，但再次感觉真的很……如果我没有进行很多数据库迁移，我会坚持我的第一个建议。