Subject | Re: about computed fields performance |
---|---|
Author | Adam |
Post date | 2006-08-03T23:57:42Z |
--- In firebird-support@yahoogroups.com, "Anderson Farias"
<peixedragao@...> wrote:
I found the use of computed fields that require a query to be
impractically slow. Computed fields that are based on values available
in the current record are fine.
I don't know the answer to your question, but I do know that you will
want an index on contact (vendor, cdate desc). I would personally
avoid adding these computed fields at all, and simply create a view
that contained these fields.
Adam
<peixedragao@...> wrote:
>Anderson,
> Hi all,
>
> I have a doubt about computed fields. Let´s say a have this table:
>
>
> create table vendor (
> code integer not null,
> name varchar(30) not null,
> phone varchar(20),
>
> last_contract computed by (
> (select max(cdate) from contracts where vendor=vendor.code)),
>
> total_amount computed by (
> (select sum(totalvalue) from contracts where
> vendor=vendor.code)),
>
> constraint pk_vendor primary key (code)
> );
>
>
> now, what I want to know is if by doing a select on this table, only
> against non computed fields (eg. select name, phone from vendor)
> will couse Fb to calculate fields last_contract and total_amount ?!?
>
> putting it another way, do I have 'performance hits' when querying
> only non computed fields on tables that do have computed fields
> (like those I mentioned above) ?!
>
> Thanks for any comment,
I found the use of computed fields that require a query to be
impractically slow. Computed fields that are based on values available
in the current record are fine.
I don't know the answer to your question, but I do know that you will
want an index on contact (vendor, cdate desc). I would personally
avoid adding these computed fields at all, and simply create a view
that contained these fields.
Adam