C# 首先使用实体框架代码将SQL表主键定义为区分大小写

是否可以先在实体框架代码中定义SQL区分大小写的主键？我知道默认情况下，SQL对于字符串是不区分大小写的，只是为了清楚，我不想将整个DB定义更改为区分大小写的，只有一个表列（主键）

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

理想情况下，我希望找到一种方法，通过实体框架将主键定义为区分大小写的，而不是使用

如果您有任何建议，或者最好是一个简单的方法，我将不胜感激

更新

好吧，我对这一点几乎失去了希望，现在当我尝试使用另一种方法时，那就是：

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个）

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

这是自动生成的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

---

我还发现了第二种方法，它是全自动的，在定义了很多其他东西之后，它使用了自定义数据注释。有关更多信息，请参见下面的回答。

实体框架没有内置任何功能，它将始终使用默认排序规则创建数据库和列。但是，您可以在migration

Up（）

方法中手动运行一些SQL来修改特定列的排序规则：

Sql("ALTER TABLE yourTable ALTER COLUMN YourColumn VARCHAR(50) COLLATE Latin1_General_CS_AS");

---

到目前为止，我得到的最好的解决方案（我也不认为它是一个好的解决方案）是用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\u Latin1\u General\u CP1\u CS\u添加为

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

解决方案2

我可以确认它也能起作用，这有点过分了。您可以定义自己的数据注释，这里我们定义一个自定义的

[区分大小写]

。

---

工作真的很好，但再次它真的感觉到很多。。。如果我没有太多的db迁移，我会坚持我的第一个建议。

你在使用迁移吗？是的，我有，你有什么建议吗？看起来EF Core正在考虑迁移，->我感谢你的回答，但我已经知道了这个选项。在我提供的链接中。我希望有一种方法可以从EF中实现，或者有一种创造性的解决方法，以防没有。@LiranBo-Hm，我没有读过链接（可能应该读过），但没有，没有其他方法可以实现。嗯，您可能会编写自己的自定义属性，然后以某种方式挂接到EF中，但这将需要大量代码。