所以最近在我正在进行的一个项目中，我们一直在努力保持解决方案的代码库和相关的数据库模式同步（数据库 = SQL Server 2008）。
数据库更改相当频繁地发生（添加列、约束、关系等），因此人们从源代码管理中执行“获取最新”并发现他们也需要重建数据库并不少见（有时他们忘记做后者）。
我们没有使用 VSTS：数据库版 (DataDude)，而是使用带有脚本（批处理文件）的标准 Visual Studio 数据库项目，该脚本从 T-SQL 脚本中拆除并重新创建数据库。该解决方案是一个 .Net 和 ASP.net 解决方案，使用 LINQ to SQL 作为 ORM 底层。
任何人都对采取的方法（无论是否自动）有想法，这将使每个人都了解最新的数据库模式？
与 MSBuild 的持续集成是一种选择，但仅有助于获取任何已提交的重大更改，在我上面强调的场景中并没有真正的帮助。
如果有帮助，我们正在使用 Team Foundation Server。
我们尝试从创建脚本开始。
也就是说，除非脚本已经过测试并检查到源代码管理中，否则对数据库的更改是不被授权的。
但这假设数据库团队与您的应用程序团队集成在一起，这在大型项目中通常不是这种情况......
（我很想“很难”回答这个问题）
编辑：如果您的流程不正确，工具将无济于事。
好的，虽然它不是整个解决方案，但您应该在应用程序代码中包含一个断言，该断言链接到数据库以断言正在使用正确的模式，这样至少它变得显而易见，并且您避免了无声的错误和人们抱怨这些东西突然疯了。
至于模式版本，如果可用，您可以使用一些特定于数据库的功能，但我个人更喜欢声明一个模式版本表并将版本号保留在那里，这样它就可以移植并且可以通过一个简单的选择语句进行检查
看看 DB Ghost - 您可以使用脚本在几秒钟内创建一个 dbp，然后使用更改管理器管理您的所有数据库代码。www.dbghost.com
这正是 DB Ghost 旨在处理的问题。
我们基本上按照您的方式做事，生成脚本也检查到源代码控制中。我是指定的数据库管理员，所以对脚本本身的所有更改都是通过我完成的。人们向我发送他们所做更改的脚本，我更新架构的主副本，运行生成脚本 (SSMS) 以生成新的数据库脚本，然后将其签入。我将我的代码副本与任何其他地方正在进行的更改。我们是一家小商店，所以这对我们来说效果很好。我意识到它可能无法扩展。
如果您不使用 Visual Studio 数据库专业版，那么您将需要另一个工具来将数据库分解为其基本部分，以便以更轻松的方式管理和更改它们。
如果您想保持对所有数据库更改和更新的理智，我建议您认真考虑Redgate 的 SQL 工具。
使用RedGate SQL Compare之类的工具在任何给定版本的数据库之间生成更改模式。然后，您可以将该文件签入源代码控制
看看这个问题：数据库的动态补丁。我认为这与您的问题非常相似，可以提供帮助。
我对这个问题的解决方案很简单。将所有内容定义为 XML，并确保数据库、ORM 和 UI 都是从该 XML 生成的，没有例外。这样，您可以使用代码生成工具快速重新生成数据库创建脚本，这将改变您的架构，同时（希望）保留一些数据。这需要一些努力，但最终结果是值得的。