TM1 Forum

I'd like to ask you guys if there is any best practice advise you can give on whether to create report on the data entry cube or creating a cube for reporting. What are the things to consider when it comes to creating the design. Cause for example if the data entry fields are exactly the same, would it be necessary to create a duplicate cube to transfer the data to it and report from that cube? Especially when it comes to performance. Any pros & cons?

appleglaze28 wrote:I'd like to ask you guys if there is any best practice advise you can give on whether to create report on the data entry cube or creating a cube for reporting. What are the things to consider when it comes to creating the design. Cause for example if the data entry fields are exactly the same, would it be necessary to create a duplicate cube to transfer the data to it and report from that cube? Especially when it comes to performance. Any pros & cons?

I can't quite fathom any reason, aside from an urgent and insatiable desire to add layer upon layer of redundant complexity, for having an input cube and a reporting cube. Certainly not ones which are duplicates of each other. The whole reason for TM1 having write-back capability is to allow input to and output from the same place. Want to freeze the input at a certain point? Use security. It makes more sense than carrying the data twice, interlinked by unnecessary interfaces and/or rules and/or replications.

Alan Kirk wrote:I can't quite fathom any reason, aside from an urgent and insatiable desire to add layer upon layer of redundant complexity, for having an input cube and a reporting cube. Certainly not ones which are duplicates of each other. The whole reason for TM1 having write-back capability is to allow input to and output from the same place. Want to freeze the input at a certain point? Use security. It makes more sense than carrying the data twice, interlinked by unnecessary interfaces and/or rules and/or replications.

I can. Caching and performance.

If you have large cubes and/or lots of rule calculations then quite possibly some high level views might take quite-a-while to open. If the views are pre-constructed then you can get much better performance for users. Any change to cube data blows away the calculation cache and view cache for the cube (which also blows away the benefit of pre-calculating and caching.) So having separate data entry and reporting cubes is conceivable. In most instances its not warranted, but in some it is.

lotsaram wrote:

Alan Kirk wrote:I can't quite fathom any reason, aside from an urgent and insatiable desire to add layer upon layer of redundant complexity, for having an input cube and a reporting cube. Certainly not ones which are duplicates of each other. The whole reason for TM1 having write-back capability is to allow input to and output from the same place. Want to freeze the input at a certain point? Use security. It makes more sense than carrying the data twice, interlinked by unnecessary interfaces and/or rules and/or replications.

I can. Caching and performance.

If you have large cubes and/or lots of rule calculations then quite possibly some high level views might take quite-a-while to open. If the views are pre-constructed then you can get much better performance for users. Any change to cube data blows away the calculation cache and view cache for the cube (which also blows away the benefit of pre-calculating and caching.) So having separate data entry and reporting cubes is conceivable. In most instances its not warranted, but in some it is.

Fair point. Though as you indicate in the last paragraph, it's more likely to be an exception rather than a rule. There's no point doing it just for the sake of doing it, or to try to "compartmentalise" data into input and output sets. Unless you have some really serious performance issues that the caching can overcome (in which case the first thing to do is make sure that the rules are optimised) then splitting them increases maintenance issues, and also loses you "real time" performance resulting in users possibly seeing out of date data.