Question

我在本地计算机上安装了SQL Server 2012，并且我正在使用Arvixe托管我的应用程序/数据库的生产版本。

要使用Arvixe在远程服务器上初始设置数据库，我刚刚上传了本地数据库的.bak文件。没什么大不了的，因为它只是设置了东西，但是你知道这也将我的所有测试数据推送到我的生产服务器上的数据库。

我的问题是这个..我应该如何将数据库更改（新表，列，键等）从本地开发环境推送到Arvixe服务器上的生产环境？一个简单的备份现在不能工作 - 我无法覆盖我的生产数据并用dev数据替换它。

我可以用这个程序吗？ SQL Server 2012中有什么东西我只是缺少了吗？我只能找到上传本地数据库备份版本的建议。

感谢您的帮助。

Answer 1

将数据库更改从开发推送到生产的方式与生产实例的位置几乎没有任何关系。

应通过转发脚本将所有更改迁移到其他环境：

您应该在进行这些更改时为所有更改创建脚本。
脚本应放在特定版本的文件夹中。
脚本应编号为保持发生这些更改的相同时间顺序（这应该消除 - 主要是 - 任何依赖性问题）。
脚本编号应与2或3位数一致，以便正确排序（即01,02，...或001 001，...）。
脚本应该都可以重新运行（即他们应该首先检查是否已经发生了预期的更改，如果是，请跳到下一个脚本）。
迁移到更高的环境时，只需运行所有脚本。
如果任何脚本失败，整个过程应该终止，因为所有更改都需要按照它们在开发中发生的顺序进行。如果使用 SQLCMD.EXE 来运行脚本，请使用-b（即“On error batch abort”命令行开关），因为它会在出现任何错误时终止进程。'
这是一个简单的CMD脚本（你可以命名为 DeploySqlScripts.cmd ），它一次处理一个文件夹，一个服务器/实例，并假设你有一个{每个脚本顶部的{1}}行：
```
USE [DatabaseName];
```

此外：

如果您要从Dev迁移到Prod，那么您至少缺少一个环境，如果不是2或甚至3个。您不应该直接将更改从开发推送到生产，因为您可能正在开发非准备发布。您认为可以发布的所有更改应首先进入QA环境，以提供更好的测试，因为它没有任何可能使某些测试无效的其他更改。
您确实应该在源代码控制系统（a.k.a.版本控制系统）的源代码中拥有您的数据库对象CREATE脚本。 Subversion（SVN），Git，TFS等。有几个选项，每个选项都有它们的优点和缺点（以及真正的信徒和仇恨者）。因此，对其中一些进行一些研究，选择一个适合您需求的研究，然后使用它。是的，发布脚本也应该是该存储库的一部分。
还有一个来自Redgate的工具，SQL Source Control，这个工具不是免费的，我没有使用它，但是在这方面寻求帮助。
对于简单/小型项目（单个数据库），Microsoft有一个免费工具，可以编写源（即开发）和目标（即QA或生产）之间的差异。它被称为SqlPackage.exe，是SQL Server Data Tools (SSDT)的一部分。

Answer 2

您可以对您有兴趣推送的数据库对象设置触发器，并将生产服务器设置为链接服务器。另外，将生产数据推送到开发环境很好，但另一方面涉及很多风险。