如果我们可以直接基于 RAW 表构建视图，则需要 OLAP 多维数据集
假设源数据中的表是干净的并且处于可以直接使用的状态。
我试图了解基于 RAW 表构建视图是否比创建多维数据集更好。为了使视图动态化，我们可以使用 .NET 应用程序，该应用程序将获取视图的参数并执行带参数的视图并获取用于报告和分析的数据。
如果我想查看 2 月份美国产品的销售额。因此，我可以创建一个视图，连接产品，客户获取二月份特定一天的销售额。
而不是使用产品、日期、客户维度形成星型架构。我真的很想了解一家公司应该遵循的标准是什么。
有人告诉我，立方体只适合分析，不适合报告。无论我们想要什么信息，我们都可以通过创建动态视图来获取。
对此有什么建议或想法吗？
谢谢！！
Assume that the table in the source data is is clean and in a state where they can be used directly.
I am trying to understand whether building views based off the RAW table is better than creating cubes. To make the VIEWS dynamic, we can have .NET application which would take paramteres for the view and execute a View with Parameters and get the data for Reporting and analysis.
If I want to view the Sales of a Product for United states in the Month of Februaray. So, I can create a view joining Product, Customer get the sales for a particular day in the month of February.
Instead of forming a Star Schema with Product, Date, Customer dimension. I am really trying to understand what is the standarad a company should go with.
I have folks telling Cubes are only good for analysis not good for reporting . Whatever information we want we can get it by creating a DYNAMIC Views
Any advise or ideas on this ?
Thanks!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
顾名思义，SSAS（SQL Server Analysis Services）确实是为分析而构建的。其原因是高度规范化的表结构（例如星型模式）允许超高效的索引与聚合值的预处理相结合。
视图是获取 OLTP（与 OLAP 相比）数据库中已存在的数据并以更适合您的查询需求的方式对其进行转换的好方法。这与“获取”存储过程的工作方式相同。
现在我的观点是：
如果您有少量数据（相对于服务器的能力以及许多其他因素）并且您没有对数据执行密集的聚合，请考虑使用存储过程来访问数据库。您可以像任何其他函数一样在 .NET 中指定参数，从而使此方法超级简单。
如果您有大量数据（例如超过 1 亿行），请考虑创建多维数据集。这将使您的查询更加顺畅。这些方面还有很多工作要做，但速度回报是巨大的。
尾注：
如果报告中的数据与数据库中已有的数据非常相似（包括连接表），并且行数少于 5 亿行，则只需使用存储过程，并考虑使用 SSRS（或不使用）。如果您有大量数据需要聚合和转换，请查看 SSAS OLAP 多维数据集。
As the name suggest SSAS (SQL Server Analysis Services) is indeed built for analysis. The reason for this is the highly normalized table structure (e.g., the star schema) which allows for super efficient indexing combined with the pre-processing of aggregated values.
Views are a great way to take data that already exists within your OLTP (as compared to OLAP) database and transform it in a manner that better fits your querying needs. This works in the same manner as "get" stored procedures.
Now for my opinion:
If you have a small amount of data (relative to the power of your server, as well as many other factors) and you're not performing intense aggregations of the data, consider using stored procedures to access your database. You can specify the parameter in .NET like any other function, making this method super easy.
If you have a lot of data (like, over 100 million rows), consider creating a cube. This will allow your queries to fly. There's a lot more work that goes into these, but the speed payoff is huge.
End note:
If the data in your reports is pretty similar to the data you already have in your database (including JOINing the tables) and you have under half a billion rows, just use a stored proc, and look into using SSRS (or not). If you have a ton of data that needs to be aggregated and transformed, look into SSAS OLAP cubes.
根据我对 Microsoft 分析服务的有限经验，我同意 Norla 的观点。如果视图的执行时间合理，那就是正确的方法。当然可以针对多维数据集进行报告，因为 SQL Reporting Services 可以很好地适应它们，但是当使用多维数据集作为数据源时，开发过程通常会涉及更多内容。
From my limited experience with Microsoft's Analysis Services, I would agree with Norla. If the execution time of the view is reasonable, that would be the way to go. Cubes can certainly be reported against, as SQL Reporting Services accommodates them fairly well, but the development process can often be much more involved when using a cube as your data source.
构建视图可以作为小型数据集的替代方案。你可以考虑走那条路但是：
1) 一旦报告需要花费大量时间来加载
2）它减慢了事务系统的速度
那么你就必须考虑立方体。
Building views can be an alternative for small datasets. You could consider going that route BUT:
1) once the reports are taking a lot of time to load
2) It slows the transactional systems
Then you'll have to consider cubes.