SSMS解决方案和项目的替代方案？

根据官方的SQL Server文档，不建议使用“解决方案，项目和项目”。MSDN页面顶部的明显（尽管有些隐晦）警告标语指出：

“此功能将在将来的Microsoft SQL Server版本中删除。请避免在新的开发工作中使用此功能，并计划修改当前使用此功能的应用程序。”

不幸的是，没有提供替代存储/容器策略的建议。那么，推荐用于存储和打包构成数据库应用程序的各种脚本，查询和文件的方法是什么？我也很想知道你们中的任何人在当前工作中是否正在使用解决方案或项目框架，以及它们的用途。

[注意：我意识到我可以使用VS2010来实现此功能，但是我对基于SSMS的方法很感兴趣（出于此问题的答案中所表达的原因）。

在这两行之间阅读，我猜期望/计划是将SQL Server数据工具（SSDT）项目类型扩展到SSMS以用于SQL 2012的发行。显然，这没有发生，因此我们坚持使用（坦白地讲，可怕的是）SSMS对项目的解释。

如果您想管理数据库源，则应该深入研究SSDT。我目前正在将其用于一个未开发的项目，还将一个大型的Brownfield数据库移至该项目。小问题和痛苦点，但没有障碍，我们已经在投资时间上获得了回报。

Jamie Thomson在VS2010 Database Projects（前身）上发表了大量博客，他已开始在SSDT上发表文章，并且似乎和我一样忠实。Bob Beauchemin是另一个值得追随的早期采用者。

如果您想组织随机脚本的集合（而不是完整的数据库构建），则可以，但是所提供的支持并不十分“一流”。为此，创建一个标准的SSDT项目类型，然后在文件属性中将脚本更改为编译类型“ None”。

在Red Gate，我们刚刚发布了一个与SSDT一起使用的SQL Source Control版本，它提供了一种从SQL Server Management Studio管理和源代码控制数据库更改的方法，可以与数据库项目存储库一起使用。

可以在SSDT论坛本身上找到更多详细信息和下载链接：

http://social.msdn.microsoft.com/Forums/zh-CN/ssdt/thread/0c763f98-c55a-44a7-9100-80a6d9223d04

这是一个免费的Beta版本。我们目前正在寻求社区反馈，然后再将此功能合并到完整版本中。