Performance regarding transposing fact data

Hello

I have an Analysis Services performance question:

Scenario:

My Fact table has a column that indicates some value-ID and only one value column. Out of this fact table I'd like to create a cube with two measures, one for each value-ID. So I could either write a query like

Code Snippet

SELECT key1, key2,

sum(case valueID when 'A' then value else null end) as measureA,

sum(case valueID when 'B' then value else null end) as measureB

FROM myFacts

GROUP by key1, key2

Then I'd use this table or view as fact table.

Or I could include the case syntax directly in the measure definitions inside Analysis Services and use the original table.

Does anybody know what's better concerning performance

-regarding cube processing?

-regarding querying the cube?

Are there other things that make one solution the better one?

Hi,

If you use your select statement to load the data into the cube.

-Processing will be slower as it has to execute the case statement

-Querying will be faster

If you read in the values with out the case statement

-Processing will be quicker as it doesn't have to execute the case statement

-Querying will be slower, you will have to create to MDX calculated measures that do the same as you are showing.

If you use your group by select statement, the granularity of your fact is also going to change - is that really what you want?

I would just create two MDX calculated measures, does depend on the size of data I suppose.

CREATE MEMBER CURRENTCUBE.[measures].[measureA] as

([Measures].[Value],[Dimension].[Dimension Key].&)

,non_empty_behavior = [Measures].[Value],VISIBLE = 1;

Might look something like above - ish

Hope that helps,

Matt

|||

Hi Matt

Thank you for your reply.

(First I apologize for not having added that I'm using Analysis Services 2000 not 2005.)

Generally I don't want to create a calculated member for each measure becaus calculated members are only calculated during run time but I want to have the measures correct after the cube was processed.

In Analysis Services 2000 I don't have the ability to use a select statement as a source for a fact table. Instead a table or view must exist in the underlying datasource. So there I have the possibility to either create a table or view with the select statement above or I enter the case expression inside the measure definition. So somewhere the case will be executed because having a dimension like "valueID" is not what I want or, wait, ...maybe it could be also a possible solution to have just one measure in the cube and have a valueID dimension... But this leads to more difficult queries and some inconveniances for cube users.

Regards

Chris

|||

Hi,

My 2000 skills are a little rusty and weren't perhaps that great in the first place

I would probably create a view, it would allow you to compare A against B or even create a total of A and B if you need to.

Sorry I can't be much help, perhaps someone else will help you.

Cheers

Matt

performance question

I've got 3 functions. one that calculates a value, and two other ones that
return a value based on the value returned by the first.
I use these in a view
example:
select
dbo.calcvalue(t.[id]) as value,
dbo.calc1(calcvalue(t.[id]) )) as val1,
dbo.calc2(calcvalue(t.[id]) )) as val2
from
tabletest t
will calcvalue() get called 3 times? or would it be more efficient to use
two views.
example:
view 1:
select
dbo.calcvalue(t.[id]) as value
from
tabletest t
view 2:
select
dbo.calc1(value) as val1,
dbo.calc2(value) as val2
from
view1user defined functions must be deterministic - give the same output for the
same input. I think one reason this restriction is there is so that sql can
eliminate performing second and third calls to your function. That said, I
don't know if it will call it more than once. You can insure it won't by
using a derived table.
select t.id, value, dbo.calc1(value) as val1, dbo.calc2(value) as val2
from
(
select id, calcvalue(id) as value
from tabletest
) as t
Jeremy wrote:
>I've got 3 functions. one that calculates a value, and two other ones that
>return a value based on the value returned by the first.
>I use these in a view
>example:
>select
> dbo.calcvalue(t.[id]) as value,
> dbo.calc1(calcvalue(t.[id]) )) as val1,
> dbo.calc2(calcvalue(t.[id]) )) as val2
>from
> tabletest t
>will calcvalue() get called 3 times? or would it be more efficient to use
>two views.
>example:
>view 1:
>select
> dbo.calcvalue(t.[id]) as value
>from
> tabletest t
>view 2:
>select
> dbo.calc1(value) as val1,
> dbo.calc2(value) as val2
>from
> view1
--
Message posted via http://www.sqlmonster.com|||Jeremy,
The rules for scalar UDFs allow for many types of optimization,
including substitution. However, a simple test will show that both SQL
Server 2000 and SQL Server 2005 will not reuse the result of the UDF for
the same row.
So if you have an expensive dbo.calcvalue, and a very cheap dbo.calc1,
then the query
select dbo.calcvalue(id), dbo.calc1(dbo.calcvalue(id)) from t
will need almost twice as long to finish when compared to
select dbo.calcvalue(id), dbo.calc1(id) from t
--
Gert-Jan
Jeremy wrote:
> I've got 3 functions. one that calculates a value, and two other ones that
> return a value based on the value returned by the first.
> I use these in a view
> example:
> select
> dbo.calcvalue(t.[id]) as value,
> dbo.calc1(calcvalue(t.[id]) )) as val1,
> dbo.calc2(calcvalue(t.[id]) )) as val2
> from
> tabletest t
> will calcvalue() get called 3 times? or would it be more efficient to use
> two views.
> example:
> view 1:
> select
> dbo.calcvalue(t.[id]) as value
> from
> tabletest t
> view 2:
> select
> dbo.calc1(value) as val1,
> dbo.calc2(value) as val2
> from
> view1

Performance of NVARCHAR(n) for large strings

What are the performance or storage implications of using a large value for NVARCHAR? For example, if I specify a NVARCHAR(4000) column just to cope with the rare case there are strings that long, but have a table full of strings 255 characters long, is the performance identical to specifying an NVARCHAR(255) column? Is there a reason then NOT to specify NVARCHAR(4000) on everything? i.e. does the query optimizer use it?

I know how long a row is and how many rows can fit in a page (4096 bytes) affects performance, but my understanding is that NVARCHAR only stores the characters needed so it wouldn't be affected unless there was actually a longer string. I wanted to know if there are any other considerations to using a large value here.

Also, how does NTEXT compare to using NVARCHAR? I noticed the documentation said it used a new page after 256 characters, which sounds like it's different from how a 4000 byte NVARCHAR would be stored?

Specifying nvarchar(4000) as opposed to nvarchar(256) when you only intend to store strings of max length 256 should not cause any significant perf hit.

On the other hand, nvarchar should be the preferable choice when compared to ntext for performance reasons. First of all, ntext (or image) cannot be indexed. Secondly, they are stored out of the row page and incur more overhead.