我们有18个数据库，它们应该具有相同的架构，但是没有。在某些情况下，一个表被添加到一个表中，但其余表未添加。或者，在少数数据库中需要某些存储过程，而其他数据库则不需要。或者，我们的DBA忘记运行脚本来添加所有数据库的视图。

使数据库架构保持同步的最佳方法是什么？

解决方案

Red Gate的SQL Compare是一个很好的工具。

对于旧版修复/清理，有一些工具(例如SQLCompare)可以生成脚本来同步数据库。

对于运行SQL Server的.NET商店，还有Visual Studio Database Edition，它可以为架构更改创建更改脚本，可以将其检入源代码管理，并使用CI / build流程自动生成。

我没有足够的声誉来评论上面的答案，但是SQL Compare的专业版具有可编写脚本的API。鉴于我们必须将内容复制到所有这些数据库中，因此可以使用它来进行自动化作业，以生成更改脚本或者验证数据库是否全部同步。它也没有比标准版本贵多少。

除了使用数据库比较工具之外，对于18个数据库，我们还应该拥有一个DBA，因此，通过限制对CREATE和ALTER的访问仅限于DBA，可以强制执行仅DBA可以在数据库级别更改表的策略。在测试数据库和实时数据库上。当然，开发数据库不应该有这个！让曾经创建或者更改模式的开发人员可以通过DBA随意进行。

SQLCompare是我用来发现数据库之间的差异并使它们同步的最佳工具。

为了保持数据库同步，我们需要准备好几件事：

1)我们需要有关谁可以更改生产的策略。通常，这只能是DBA(大型组织的DBA团队)和1或者2个后援。备份仅应在DBA不在时或者紧急情况下进行更改。不应定期部署备份。根据此策略设置数据库权限。

2)管理部署请求的过程和工具。理想情况下，我们将具有开发环境，测试环境和生产环境。开发人员应在开发环境中进行初始开发，并在适当时将更改推送到测试和生产中。我们将需要某种方式让DBA知道何时进行更改。我不建议我们大声疾呼下一个立方体。大型组织可能有一个变更控制委员会，而变更每月只进行一次。较小的公司可能只是让开发人员请求测试，而在测试通过后，便要求将其部署到生产中。我曾在一家较小的公司工作过，使用"问题跟踪器"来满足这些要求。

使用适合情况和预算的任何方法，只要有一个流程，并拥有适用于该流程的工具即可。

3)我们说过，有时对象只需要进入少数几个数据库。由于只有18个数据库(可能在一台服务器上)，我建议使每个Databse完全匹配对象。只有5个DB需要usp_DoSomething？所以呢？将其放在每个数据库中。这将更容易管理。我们在具有约250-300个DB的6服务器系统上以这种方式进行了此操作。有例外，但它们被分组。服务器C上的数据库获得了这套额外的对象。服务器L上的数据库还有其他设置。

4)我们说过，有时DBA忘记将更改脚本部署到所有DB。这告诉我他/她需要用于部署更改的工具。他/他可能正在使用一个SQL脚本，在Query Analyzer或者Manegement Studio(或者我们使用的任何工具)中打开它，然后手动进入每个数据库并执行SQL。这不是一个好的长期(或者短期)解决方案。 Red Gate(上面是SQLCompare的制造商)拥有许多出色的工具。 MultiScript看起来可以用于部署目的。我与使用O-SQl在SQL Server 2000中编写了自己的工具的DBA一起工作。它将获取一个SQL文件，并在服务器上的每个数据库上执行该文件。他必须在每台服务器上执行它，但是胜过在每个DB上执行。我还帮助编写了一个VB.net工具，该工具可以执行相同的操作，除了它还会通过服务器列表，因此只需要执行一次。

5)源代码管理。我目前的团队没有使用源代码管理，我没有足够的时间告诉我们这会导致多少问题。如果我们没有某种源代码控制系统，请购买一个。

为每个发行版创建一个由源代码控制的DDL / SQL脚本，并且仅使用它来更新数据库。差异工具可能很有用，但主要用于检查我们没有犯错，以及在策略失败时摆脱麻烦。将DDL，SQL和存储过程脚本合并到一个脚本中，这样就很难"忘记"运行其中一个脚本。

我们有一个名为DB Schema Difftective的工具，可以比较和同步数据库模式。使用我们的其他工具DB MultiRun，我们可以轻松地将生成的(同步)脚本部署到多个数据库服务器(基于项目)。