calculate cummulative or store it

hi,
i have read many time in this newsgroup where the experts say you
should not store calculated fields and it should be handled at the
frontend. But if i want to calculate cummulative (cummulative of 6-7
years)everyday,then running a query which calculates the cummulative
for past 6-7 years the query will take time to run. but if i store
that cummulative figures everyday the query is faster. The only
sacrifice i need to make is space to store this calculated values,
which i don't think should be a problem.
Please suggest which is the better approach.Praddep
Have a look at an indexed view?
Here is an example written by Steve Kass
create table T (
i int,
filler char(1000) default 'abc'
)
go
create view T_count with schemabinding as
select
cast(i as bit) as val,
count_big(*) T_count
from dbo.T group by cast(i as bit)
go
create unique clustered index T_count_uci on T_count(val)
go
insert into T(i)
select OrderID
from Northwind..[Order Details]
go
set statistics io on
select count(*) from T
go
select sum(T_count) from T_count with (noexpand)
go
set statistics io off
-- uses an efficient query plan on the materialized view
go
drop view T_count
drop table T
"Pradeep" <agarwalp@.eeism.com> wrote in message
news:364c5b9b.0502162102.4cf2a1e5@.posting.google.com...
> hi,
> i have read many time in this newsgroup where the experts say you
> should not store calculated fields and it should be handled at the
> frontend. But if i want to calculate cummulative (cummulative of 6-7
> years)everyday,then running a query which calculates the cummulative
> for past 6-7 years the query will take time to run. but if i store
> that cummulative figures everyday the query is faster. The only
> sacrifice i need to make is space to store this calculated values,
> which i don't think should be a problem.
> Please suggest which is the better approach.|||Thanks Uri. But i am using Access 2000 and not SQL. So in Access i
have a predefined query which does the cummulative. But since i have
to calculate it everyday and the data is for more than 2000 rows it
takes time to do the calculation. Storing the calculated values might
improve the performance.
Thanks
"Uri Dimant" <urid@.iscar.co.il> wrote in message news:<O#riAaLFFHA.3928@.TK2MSFTNGP15.phx.gb
l>...
> Praddep
> Have a look at an indexed view?
> Here is an example written by Steve Kass
> create table T (
> i int,
> filler char(1000) default 'abc'
> )
> go
> create view T_count with schemabinding as
> select
> cast(i as bit) as val,
> count_big(*) T_count
> from dbo.T group by cast(i as bit)
> go
> create unique clustered index T_count_uci on T_count(val)
> go
> insert into T(i)
> select OrderID
> from Northwind..[Order Details]
> go
> set statistics io on
> select count(*) from T
> go
> select sum(T_count) from T_count with (noexpand)
> go
> set statistics io off
> -- uses an efficient query plan on the materialized view
> go
> drop view T_count
> drop table T
>
> "Pradeep" <agarwalp@.eeism.com> wrote in message
> news:364c5b9b.0502162102.4cf2a1e5@.posting.google.com...|||On 17 Feb 2005 02:46:41 -0800, Pradeep wrote:

>Thanks Uri. But i am using Access 2000 and not SQL. So in Access i
>have a predefined query which does the cummulative. But since i have
>to calculate it everyday and the data is for more than 2000 rows it
>takes time to do the calculation. Storing the calculated values might
>improve the performance.
Hi Pradeep,
That is exactly why Uri recommended you to investigate indexed views. You
can find the information in Books Online.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Under normal circumstances, you shouldn't store calculated fields. From you
r
question I assume that you want to store data aggregated from one table in
another. The problem with that is the additional housekeeping required to
keep the aggregate synchronized when the original table changes. Every
program that modifies the original table must also update the aggregate
value. Furthermore, Every program that calculates the aggregate value must
calculate it in the exact same manner. The experts are correct, because of
the additional programming required to ensure that the data remains
consistent and the possibility that a minor difference in one calculating
program can introduce database inconsistencies that are extremely difficult
to find. The best course is to first try an index, and only if that fails,
to add the aggregate field and the triggers on the original table that
maintains the aggregate.
"Pradeep" wrote:

> hi,
> i have read many time in this newsgroup where the experts say you
> should not store calculated fields and it should be handled at the
> frontend. But if i want to calculate cummulative (cummulative of 6-7
> years)everyday,then running a query which calculates the cummulative
> for past 6-7 years the query will take time to run. but if i store
> that cummulative figures everyday the query is faster. The only
> sacrifice i need to make is space to store this calculated values,
> which i don't think should be a problem.
> Please suggest which is the better approach.
>|||You're right that it wouldn't be sensible to do that everyday in an
Access query. The idea is to keep the calculations server-side. That's
why we have features such as indexed views and Analysis Services in SQL
Server.
On the other hand, if your data is only two or three thousand rows,
just putting the query in a stored-proc may well give you acceptable
results.
David Portas
SQL Server MVP
--