Experience with creating, using their own indicators and performance

In the next post I mention the experience with the creation, use and own performance indicators (calculated columns). Post article builds on two ways to define your own calculations (indicators) in the Business model .Custom indicator (eg, arithmetic operations on values ​​of two columns) can be defined in the following ways:

1. Directly in the design report
2. Using metadata using logical columns
3. Using metadata using physical columns

1st In the draft report

• Easy and quick setup
• Suitable for use unfrequented indicators (the indicator is only available in the report where it is created)
• The actual calculation is performed over the indicator aggregated or detailed (depending on whether the default indicator was preset in the metadata layer of an aggregate function)
• When a misunderstanding of the indicators which are based computing and application functions may be incorrect / unwanted outcome (eg, averaged totaling no indicators or see. here )
• I recommend using only if the source columns are also discussed in report
• When using columns that are not content to report high physical question of COST, which can grow up to 6 orders of magnitude
• This method of use for end users rather ad-hoc needs

2nd Using metadata using logical columns

• The term can refer to columns / indicators in the logical table (from multiple sources)
• First, aggregation is performed, and then calculate a new column which can affect the accuracy / inaccuracy of the results - see more. here
• If the referenced column report content, so everything is OK. If not, then the question has a high physical COST
• The indicator is named and delegated to the presentation layer - it can be reused

Sample final query: WITH sawith0 AS (SELECT DISTINCT t17101.is_on_us_flag AS c1, c2 AS t1339.date_dt l1_owner.d_date FROM t1339, t17101 l2_owner.a_stat_atm_agg WHERE (t1339.date_dt t17101.audit_id =)), sawith1 AS (SELECT SUM (t17101 . amt_amt) AS c1, c2 AS t1339.date_dt l1_owner.d_date FROM t1339, t17101 l2_owner.a_stat_atm_agg WHERE (t1339.date_dt = t17101.audit_id) GROUP BY t1339.date_dt) SELECT DISTINCT CASE WHEN sawith0.c2 IS NOT NULL THEN sawith0. c2 sawith1.c2 WHEN IS NOT NULL THEN sawith1.c2 END AS c1, CASEWHEN sawith0.c1 = '1 ' THEN sawith1.c1 ELSE 0 END AS C2 FROM sawith0 FULL OUTER JOIN ON sawith1 sawith0.c2 sawith1.c2 = ORDER BY c1 thirdUsing metadata using physical columns

• The term can refer to columns in the tables attached individuals (source)
• First, the calculation is performed, and the aggregation of a new column which can affect the accuracy / inaccuracy of the results - see more. here
• "Slight" COST physical inquiry and whether or not the source columns used in the report
• The indicator is named and delegated to the presentation layer - it can be reused

Sample final query: SELECT t1339.date_dt AS c1, SUM (CASE WHEN NOT LIKE '00% t5199.resp_code_cd ' t17101.trn_cnt THEN ELSE 0 END ) AS c2 FROM l1_owner.d_date t1339, t5199 lookup_owner.d_response_code,l2_owner.a_stat_atm_agg t17101 WHERE (t1339.date_dt = t17101.audit_idAND t5199.response_code_id = t17101.resp_cde_id ) t1339.date_dt GROUP BY ORDER BY c1 Conclusion From the above information, my recommendation is clear - to define their own indicators to use to the maximum extent of physical columns:

• The indicator is delegated to the presentation layer, so it can be reused by end users themselves
• There is another way of limited use (see final question)
• Lower COST physical query