on 2008 Jun 09 9:22 PM
Hi Experts!
I would like to know if there was a potentiel performance impact if a calculated key figure (CKF1) is used in another calculated key figure (CKF2) while designing queries.
In other words, which scenario is better for performance and why?
Example: CKF1 = KF1+KF2
CKF2 = KF1KF2KF3
Scenario A: CKF2 = CKF1+KF3
Scenario B: CKF2 = KF1KF2KF3
Thanks
Deepthi
When you already have CKF1 with you, its better to use it. So, A is better thatn B.
But when you dont have CKF1 already calculated, then use B.
Thanks..
Shambhu
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Deepthi Reddy,
I prefer to go for senerio B, insted of A. As Senerio A is depend on CKF1, until unless you get the value for CKF1, you will not get the CKF2 in Senerio A.
I hope you understood.
Regards,
S P.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Deepti,
In the current Scenario mentioned by you, as the calculations are not that big so it doest not make much difference in the performance.
Performance depends on the complexity of the query and calculation, and how we design the query's.
Thanks
Dipika
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It depends on how complex the calculation is.
Simply put if you already have a calculated keyfigure then it makes to sense to use it.
If you are using the CFK in multiple CFK's it is useful to create it.
For simple additions you do not need to think too much about performance issues but complex calculations might help again if you use it repeatedly.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
67 | |
8 | |
8 | |
6 | |
6 | |
6 | |
6 | |
6 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.