Calculations using Physical Tables vs Logical Tables

Question

It's easy to find an example of where you would want to use Logical Tables instead of Physical Tables to create fact columns in the repository. Any measure such as Profit Margin (i.e. Profit / Sales) must be computed in the Logical Tables, so that the division operation occurs after the dimensional aggregations are passed to it from the physical layer. In the example of (Profit / Sales), using Physical Columns returns an incorrect result, because it does the division operation first, then aggregates all of those results into a nonsense value.
So, is there some type of formula in which the reverse is true, such that using Logical Tables would return an incorrect result, while the Physical Tables would return the correct result?
If not, then under what circumstances would we want to use the Physical Tables instead of the Logical Tables? Is there some type of formula that performs better with Physical Tables?

Answer 1

Hi Thomson,
calculations using physical columns generate fair SQL which wouldn't involve any sub-selects in physical query... and would be fast.
If you use logical columns by selecting the “Use existing logical columns as the source check box" in rpd, most of the times it generates queries.. with sub-selects (means subqueries)
Ex: suppose you are calculating a calculation based on 2 columns a, b then
If you use, Logical columns, the query would be something like...
*Select D1.C1 + D1.C2*
*From (select Sum(X) as C1,*
*Sum(Y) as C2*
*From FactX) D1*
*Group by DimY*
If you use, phyiscal columns for calculation the... the query would be...
*Select Sum(D1.C1 + D1.C2)*
*From FactX*
*Group By DimY;*
which is much preety and good to query the database... without any difficult..
For first query... it's using inner queries... so process would be slow...
+Thanks & Regards+
+Kishore Guggilla+