Visual Studio 2015/2017 中的 BI 解决方案答案

【问题标题】：BI solutions in Visual Studio 2015/2017Visual Studio 2015/2017 中的 BI 解决方案
【发布时间】：2018-08-03 19:07:53
【问题描述】：

我正在 Visual Studio 2015 中将一组不同的解决方案重新组织成新的 BI 解决方案。生成的解决方案将包含一个 SSRS 项目、一个具有 BIML 的 SSIS 项目和两个受 GIT 源代码控制的 SSDT 项目。

SSDT 项目将作为解决方案中的部分项目，仅包含与 BI 解决方案相关的非模式数据库对象。（例如存储过程、函数、视图和同义词）。

数据库的基于模式的对象将位于 GIT 源代码控制下的单独 SSDT 项目中。

这被认为是最佳做法吗？

【问题讨论】：

【解决方案1】：

这是一个基于意见的问题，因此可能会被否决、批评或没有回应。

答案是，这取决于最适合您的方式。对我来说，不，所有项目都应该分成自己的解决方案。这使事情更易于管理 - 没有什么比一个解决方案更糟糕的了。此外，您还可以获得能够以不同组合将解决方案组合在一起的优势。更不用说在 Visual Studio 验证整个解决方案时打开解决方案需要时间。

小心点。

【讨论】：

在报表解决方案中会有 rdl 对象，但您是否必须打开另一个解决方案才能查看与该项目相关的存储过程或视图？
@Renegrin 我不知道。在报表中管理存储过程的两个选项是报表中的嵌入数据集或项目中的共享数据集。我认为最好将报表源查询存储为服务器上的存储过程，然后将它们作为存储过程引用，这样您就可以对查询进行更改而无需重新部署报表。
我希望该解决方案能够提供使用存储过程的上下文并在源代码控制中管理它们。否则，我将在进行更改时打开一个或多个其他解决方案以在版本控制中检查它们。想法？
@Renegrin 听起来你想把所有东西放在一起。就这样做吧。您就这是否是最佳做法征求意见。正如我之前所说，我认为不是。在这种情况下，将存储过程保存在单独的 *.sql 文件中，并将其签入源代码管理。在源代码管理中，您可以弄清楚如何在逻辑上将所有内容组合在一起。尝试在解决方案中完成所有这些操作会使您的解决方案膨胀，而解决方案的设计并未考虑到这种意图。