如何用FluentMigrator编写存储过程？Script/EmbeddedScript/Sql何时使用？

问题描述 #

请问使用FluentMigrator编写存储过程的最佳方式是什么？同时想了解Script、EmbeddedScript和Sql这三种方式分别适合在什么场景下使用？相关代码示例如下：

Migration类代码 #

[Migration(1)]
public class TestCreateUserTable : Migration
{
    public override void Up()
    {
        Execute.Script("myscriptUP.sql");
        Execute.EmbeddedScript("myscriptUP.sql");
        Execute.Sql("CREATE TABLE Users");
    }

    public override void Down()
    {
        Execute.Script("myscriptDOWN.sql");
        Execute.EmbeddedScript("myscriptDOWN.sql");
        Execute.Sql("DELETE TABLE Users");
    }
}

myscriptUP.sql #

"CREATE TABLE Users"

myscriptDOWN.sql #

"DELETE TABLE Users"

编写存储过程的最佳方式 #

1. 优先使用独立SQL脚本：将存储过程的完整逻辑放在单独的SQL文件中，而非硬编码到C#代码中，更符合SQL编写习惯，便于单独调试、版本控制和团队协作。
2. 确保回滚逻辑可靠：在Down方法中编写对应的存储过程删除/回滚脚本，避免迁移失败后无法恢复。
3. 使用幂等性SQL：在存储过程脚本中使用CREATE OR ALTER PROCEDURE（支持的数据库），或先判断存储过程是否存在再删除重建，避免重复执行时抛出错误。

三种执行方法的适用场景 #

1. Execute.Sql() #

• 适用场景：
  • 处理简短、简单的SQL语句，比如单表创建、简单索引添加、少量静态数据插入等，内联在代码中不影响可读性。
  • 需要动态生成SQL的场景（注意用参数化避免SQL注入），比如根据程序变量拼接条件或表名。
  • 小型测试类Migration，无需单独维护脚本文件的快速验证场景。
• 特点：Migration逻辑一目了然，但复杂SQL会导致C#代码臃肿，不利于SQL独立调试。

2. Execute.Script() #

• 适用场景：
  • 存储过程、视图、触发器等复杂SQL逻辑，需要单独编写、调试和维护的脚本，文件存放在项目目录中，方便团队协作编辑。
  • 脚本需要被多个Migration复用，或需独立于Migration类进行版本管理的场景。
  • 希望脚本可直接在数据库客户端（如SSMS、DBeaver）中运行调试的场景。
• 特点：脚本独立便于维护调试，但部署时需确保脚本文件路径正确，避免文件丢失。

3. Execute.EmbeddedScript() #

• 适用场景：
  • 希望将SQL脚本**打包到程序集（DLL）**中，部署时仅需发布单个DLL即可完成迁移，避免脚本文件遗漏。
  • 项目需要统一打包所有迁移资源，无需额外管理脚本文件路径的场景。
  • 脚本无需频繁修改，修改后可接受重新编译程序集的场景。
• 特点：脚本嵌入程序集，部署便捷无文件丢失风险，但修改脚本必须重新编译项目，无法单独更新脚本文件。

内容的提问来源于stack exchange，提问作者Luca La Malfa