【问题标题】:Subversion Repository Structure for MSBIMSBI 的 Subversion 存储库结构
【发布时间】:2013-11-07 06:46:21
【问题描述】:

我们刚刚开始使用 Microsoft 的工具堆栈作为我们的 BI 解决方案。

我们将为公司内的每个职能领域创建/使用 SSRS 报告、SSAS 表格模型、Excel Services.PowerPivot 模型和 PowerView 报告。

对于每个职能领域(例如“人力资源”),我们将拥有一组报告、数据模型、仪表板等

我想知道你们中是否有人可以指出正确的方向来维护版本控制下的所有项目(我们将使用 SVN)。在 SVN 下是否有维护所有这些不同类型的文件/文件夹的标准方法?

或者简单来说,您能否在下面指出使用其中一个的好处。

1) 为每个职能领域创建单独的文件夹,例如“人力资源”、“销售”等,并将与该职能领域相关的所有报告、模型存放在各自的文件夹中

文件夹结构如下所示

人力资源 -> 人力资源模型 -> HRDataModelProject1(这个级别将是 svn 的根 - 开发人员将从这个级别签出项目)
人力资源 -> 人力资源报告-> 报告项目1

Sales-> 销售模型 -> SalesModelProject1
Sales-> 销售报告 -> SalesReportProject1,

或者

2) 为每种内容类型(例如数据模型、报告等)创建单独的文件夹作为单独的文件夹,并为每个功能区域创建报告或模型

Models -> HumanResources -> HRDataModelProject1(这个级别将是 svn 的根 - 开发人员将从这个级别签出项目)
Models -> Sales -> SalesModelProject1

报告 -> 人力资源 - > HRReportProject1
报告 -> 销售 - > 销售报告项目 1

以上方法有什么优缺点吗?或者有没有其他方法可以更有效地做到这一点?非常感谢您的建议!

非常感谢,

BiDev

【问题讨论】:

    标签: svn reporting-services ssas data-modeling tabular


    【解决方案1】:

    我更喜欢第一个版本,因为它将相关的东西更紧密地结合在一起。如果将来您需要更改 HR 报告,并且可能需要在多维数据集中添加一个附加属性,这可能又需要在 ETL 过程中进行小的更改来填充,那么所有这些更改将合二为一区域,而不是分布在存储库的不同部分。

    话虽如此,您的第二个版本也可以工作,部署解决方案的管理人员可能更喜欢它,因为他们会知道在哪里可以找到集成服务包、SQL 脚本、报告或分析服务项目。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2010-11-09
      • 2011-01-22
      • 1970-01-01
      • 2010-09-27
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多