[我在 dba.stackexchange 上发布了一个相关问题，但没有得到什么回应，所以我想我会在这里发布。]
MSDN 文档是精神分裂的。在官方SQL Server 文档中，我们被告知不推荐使用“解决方案、项目和项目”。警告横幅上写着，
“此功能将在 Microsoft SQL Server 的未来版本中删除。避免在新的开发工作中使用此功能，并计划修改当前使用此功能的应用程序。”
但是，在 MSDN 文档的其他地方，使用 Projects & Solutions 仍然是存储脚本等的规定方法。
那么对于存储和打包构成数据库应用程序的各种脚本、查询和文件，您会推荐什么？我也很想知道你们中是否有人在当前工作中实际使用解决方案或项目框架，以及您使用它们的目的。
[注意：我意识到我可以将 VS2010 用于此功能，但我只对基于 SSMS 的方法感兴趣，因为我的团队的其他成员无法访问 VS（也出于此问题的答案中表达的原因） .]
我特别热衷于寻找在团队中共享 SQL 语句和查询的最佳实践——你会使用项目/解决方案（在源代码控制中备份）吗？或者自定义模板？
虽然我现在倾向于使用 Visual Studio，但我都使用过，因为这似乎是 MS 的发展方向。我可以告诉你，在 SQL Server 2012 中，项目仍然受支持并且工作正常。
老实说，无论哪种方式，我都不会出汗——IMO SSMS 项目是一种存储脚本的轻量级方式，并且（个人偏好），如果我只使用数据库，我更喜欢使用 SSMS 而不是 Visual Studio，如果除了我喜欢我的键绑定的设置方式之外，没有其他原因，而且我已经习惯了，因为我是查询分析器时代的老前辈。
对我来说，我只使用 SSMS 项目，因为如果 MS 放弃此功能，我会受到惩罚，因为我只是创建一个简单的 VS 项目并在其中创建对我的文件的引用。
我会告诉您，您应该在 MS Connect 上发布一些内容，以提醒他们注意文档中的这种差异，但是已经多年了，我从来没有对我在 Connect 上所做的任何改进提出任何建议，除了采取任何行动之外“已关闭（不会修复）”或“已关闭（按设计）”。
我知道这是一个老问题，但我在尝试找到使用有组织的数据库脚本保持轻松团队合作的最佳方式时遇到了这个问题。我通过阅读 Scott Allen 的 5 篇关于如何将数据库置于源代码控制之下的系列文章找到了一个非常好的解决方案（N 种方法中的一种），并且在使用了一段时间后，我对它非常满意并且我想它会帮助你，所以让我们分享...
查看这篇文章： http: //odetocode.com/blogs/scott/archive/2008/02/03/versioning-databases-branching-and-merging.aspx（这是第 5 篇也是最后一篇文章，请务必查看帖子 1 到 4 的“以前的条目”链接）