我们在所有项目中都使用Azure Blob存储。在项目的生命周期中，Azure中文件的命名约定发生了变化：有时我们希望重命名容器，删除额外的文件夹和其他清理操作。 但Azure不允许轻松重命名，我们必须进行复制删除。
我们也可以在开发过程中在本地更改命名约定。但是，当我们部署新版本时，我们需要记住对生产存储的确切操作。
同时我们使用Entity Framework迁移：我们更新了数据库，创建了迁移脚本。然后我们运行“update-database”并更新DB。部署脚本会自动运行相同的内容：检查生产数据库是否需要更新，并在需要时进行更新。
如果我们可以为Azure存储执行相同的迁移优势，那将会有什么好处：检查是否已应用所有迁移脚本，执行缺少脚本的进程。容器中的某处保留对最新执行脚本的引用。
这样的事情存在吗？或者我应该继续尝试并尝试自己实施。
答案 0 :(得分：2)
不，此类功能/行为不存在。并且要记住EF迁移是受支持的，并且是EF本身的一部分，而不是数据库！因此，当您谈论Azure Blob存储时 - 它作为服务不提供此类功能，与SQL Server本身不同的方式相同。
关于这样的库/代码是否存在的问题 - 没有。
你提出了一个非常有趣的问题！
我个人不是“移民”的忠实粉丝。您可以在开发生命周期的早期阶段完成此操作。但是一旦你达到GA / Production，你必须非常小心你在做什么。即使EF迁移可能适用于较小的数据库大小，但您是否愿意在具有包含数百万条记录生产数据的表的数据库上运行迁移？与blob相同。如果你有100或1000个blob可能没问题。 2M blob怎么样？您是否真的愿意放置一些可以通过2M实体并对其执行某些操作的代码，并将此代码作为构建/部署过程的一部分运行？我不愿意。