我们有几个遗留的SQL Server数据库，我们偶尔会对其进行架构更改。我们目前有一个用C ++编写的实用程序，它允许用户使用这些架构更改来更新其数据库。该实用程序当前生成动态sql以创建所有数据库对象。我正在考虑重做这一点，并认为EF迁移可能是一个很好的方法。我已经阅读了一些关于这个主题的内容，我对它是如何工作有一个大概的了解。但是我有点难以弄清楚如何设置它来替换我们当前的程序（或者甚至可能）。目前，客户端可以是许多先前版本中的任何一个。我假设我必须回到最旧的版本并从中创建我的模型/初始迁移，然后为每个版本更改生成增量迁移，以支持所有版本的更新。这是正确的假设吗？此外，目前我们的客户可能正在使用sql server 2000,2005或2008.这会对我如何设置（或者我是否可以）有任何影响？此外，目标是创建一个具有（C＃ - 可能是WPF）UI的实用程序，用户可以使用该UI来操纵迁移（最好是向上或向下）。我已经看到很多关于如何在包管理器中从命令行操作迁移的例子，但没有很多关于如何创建具有友好UI的实用程序来升级/降级生产中DB的例子。此外，我还没有看到任何显示如何在迁移中创建存储过程的东西（我们的DB依赖于某些存储过程）。我假设，如果没有别的，我可以使用Sql（）方法生成SQL查询来创建SP。那是对的吗？还有更好的方法吗？
我知道我的问题有点不具体，我为此道歉。但是我仍处于开始学习这个过程的过程中，我想知道这是否是一个好的方法。任何指导都将不胜感激。
谢谢， 丹尼斯
答案 0 :(得分：0)
首先，在SQL Server支持上，Entity Framework并不真正支持SQL Server 2000.请参阅此问题： EntityFramework SQL Server 2000?
在支持所有多个版本的问题上，您有正确的想法，需要先为最旧的版本生成初始迁移，然后逐步更改模型并生成迁移以支持更高版本。这将是一个痛苦，因为迁移是关于它们如何在数据库中表示模型的观点，并且您将做很多混乱，最终得到一个模型和一组完全代表它的迁移。具体问题是索引，列长度，数据类型，存储过程，触发器，函数，分区。
Sql()功能可以解决大多数问题，但在迁移方面也很有帮助，例如CreateIndex和AlterColumn等功能。
为了实现自动化，迁移肯定可以作为powershell cmdlet使用，它们本身就是.Net对象，因此可以通过编程方式调用。
由于这个问题已有一年之久，我认为你会决定是否这样做。我的观点是，很难看出这是值得的。如果您将使用此数据库的代码库重新平台化为Entity Framework，那么它将是有意义的。否则，数据库版本管理必将有更好的工具。我的第一个停靠点是Redgate。