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

Question

根据官方SQL Server 文档，不推荐使用“解决方案、项目和项目”。MSDN 页面顶部的显眼（虽然有些神秘）警告横幅指出：

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

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

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

Answer 1

从字里行间看，我猜期望/计划是将SQL Server Data Tools (SSDT) 项目类型扩展到 SSMS 以发布 SQL 2012。显然这没有发生，所以我们被困在 (坦率地说可怕）SSMS 对项目的解释。

如果您想要一些东西来管理您的数据库源，您应该深入研究 SSDT。我目前正在将它用于一个绿地项目，并将一个大型棕地数据库转移到它。小问题和痛点，但没有停止表演，我们已经获得了投资时间的回报。

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

如果您想组织一组随机脚本（而不是完整的数据库构建），您可以，但支持不是“一流的”。为此，请创建标准 SSDT 项目类型并将脚本更改为文件属性中的编译类型“无”。