我需要从生产数据库中恢复备份，然后自动重新应用 SQL 脚本（例如 ALTER TABLE、INSERT 等）以将该数据库模式恢复到正在开发的状态。
会有很多脚本，来自少数不同的开发人员。它们不会都在同一个目录中。
我目前的计划是在伪系统数据库的表中列出具有完整文件系统路径的脚本。然后在此数据库中创建一个存储过程，该过程将首先运行 RESTORE DATABASE，然后在脚本列表上运行光标，为每个脚本创建一个 SQLCMD 命令字符串，然后使用 xp_cmdshell 为每个脚本执行该 SQLCMD 字符串。
cursor->sqlstring->xp_cmdshell->sqlcmd 的顺序对我来说感觉很笨拙。此外，它需要打开 xp_cmdshell。
我不可能是唯一一个做过这种事情的人。有没有一种更简洁的方法来运行一组分散在服务器文件系统周围的脚本？特别是，不需要 xp_cmdshell 的方式？
首先，第一，将所有数据库脚本收集在一个中心位置。某种形式的源代码控制或版本控制是最好的，因为您可以看到谁在何时修改了什么以及（如果没有别的，使用差异工具）为什么。留下用于创建关于您的网络的数据库的代码可能会导致灾难。
其次，您需要针对您的数据库运行脚本。这意味着您需要某人或某物来运行它们，这意味着执行代码。如果您在 SQL Server 中执行此代码执行，那么您几乎最终会使用 xp_cmdshell。替代方案？使用其他可以针对数据库运行脚本的东西。
我目前对此类问题的解决方案是将脚本存储在文本 (.sql) 文件中，将文件存储在源代码管理中，并仔细跟踪它们的执行顺序（例如，CREATE TABLEs get run在添加后续列的 ALTER TABLEs 之前）。然后我有一个批处理文件——是的，我已经有一段时间了，你可以用大多数语言来做这件事——调用 SQLCMD（我们使用的是 SQL 2005，我曾经使用过 osql）并运行这些脚本针对必要的数据库。
如果您不想尝试“自己动手”，可能会有更正式的工具来帮助管理此过程。
除了 Phillip Kelley 提出的关于集中化和源代码控制的建议之外，如果您熟悉 .NET，您可能会考虑编写一个使用 SQL Server SMO（SQL Server 管理对象）的小型 WinForms 或 WebForms 应用程序。有了它，您可以将整个脚本传递给数据库，就像您将它放到 Management Studio 中一样。这避免了对 xp_cmdshell 和 sqlcmd 的需要。另一种选择是创建一个 DTS/SSIS 包，该包将读取文件并在循环中使用执行 T-SQL 任务。