Subject | Re: Computed Columns |
---|---|
Author | Adam |
Post date | 2007-04-26T23:42:08Z |
--- In firebird-support@yahoogroups.com, "Hardy Sherwood" <HardyS@...>
wrote:
multiplication or substring is a significant overhead (by the way
substring is built into 1.5 or higher).
If you need to index col2 and you need to support use Firebird 1.5,
alternative 1 may be faster for such queries. Certainly alternative 2
is easier to maintain.
There is also the option of a creating a view on your base table with
these fields.
You have still not told us whether the select will be run millions of
times and the values never change, or whether the values constantly
change and are only selected occasionally. In stable data with lots of
selects, there may eventually be a pay off for not using computed
fields. In constantly changing data with few selects, there may
eventually be a pay off for using computed fields.
I doubt either approach is measurably faster for simple manipulations.
But only you can test it fairly against the usage you expect.
Adam
wrote:
>about would
> I guess I was not all that clear on my questions concerning computed
> columns. The expressions in the computed columns I'm concerned
> only reference columns in the same row.(keycol));
>
>
>
> Here's a simple example.
>
> Alternative I. Create table alt1 (keycol integer not null, col1
> integer, col2 integer, primary key
>primary key
> Alternative II. Create table alt1 (keycol integer not null, col1
> integer, col2 computed (100*col1),
> (keycol));I don't imagine that the CPU cost of calculating a simple
multiplication or substring is a significant overhead (by the way
substring is built into 1.5 or higher).
If you need to index col2 and you need to support use Firebird 1.5,
alternative 1 may be faster for such queries. Certainly alternative 2
is easier to maintain.
There is also the option of a creating a view on your base table with
these fields.
You have still not told us whether the select will be run millions of
times and the values never change, or whether the values constantly
change and are only selected occasionally. In stable data with lots of
selects, there may eventually be a pay off for not using computed
fields. In constantly changing data with few selects, there may
eventually be a pay off for using computed fields.
I doubt either approach is measurably faster for simple manipulations.
But only you can test it fairly against the usage you expect.
Adam