I got lost after the first query, but admitedly I only have 10
minutes to check this list at the moment.

But from my experience,

Computed By fields should NOT involve other tables. It is incredibly
slow, and with any more than a couple of records, it is unusable
(exponentially slow)

Is your real table structure (ie excluding computed fields) something
like?

TableA
(
ID,
Field1,
Field2
)

TableB
(
ID,
TableAID
)

etc

if so, you do not need to put the computed fields into tableA, just
join them. If TableAID is a foreign key constraint, the index will
(in most cases) give you the performance you are after. If you still
need the computed fields in TableA (for other reasons), consider
using actual fields and having triggers fill them. That way they are
calculated on the insert and update (relatively rare) rather than the
(generally more common) select.

Adam



--- In firebird-support@yahoogroups.com, "Edson T. Marques"
<marques@o...> wrote:

> Ok!
> That was a way I found to explain my problem (poor I know!).
> In the real database those tables have complete structure with the
> apropriate indexes for the relationships and "substancial number of

rows".

> I'm having this problem with this database I'm working on. The

actual

> structure was made using those computed fields, so I fall in doubt.
> If I change this structure, if I eliminate those computed fields
> (optionally, you know, I can make joins to obtain the same result

set),

> will I have best performance if I do this (changes)?
>
> Martijn Tonies escreveu:
>
> >Hello,
> >
> >
> >
> >
> >>If my data base has a table that is related with ten other tables

and,

> >>in each one of these ten tables exists one field that I have that

to

> >>show together in a consultation with the first table. What of

this two

> >>options goes to give the best performance?
> >>
> >>
> >
> >Well, basically, the one that gives you the best performance is the
> >one that gives you the best performance.
> >
> >Given that you did not create any indices or keys, I suspect

performance

> >(on non-empty tables with a substantial number of rows) is bad in

either

> >case.
> >
> >With regards,
> >
> >Martijn Tonies
> >Database Workbench - developer tool for InterBase, Firebird, MySQL

& MS SQL

> >Server
> >Upscene Productions
> >http://www.upscene.com
> >
> >
> >
> >Visit http://firebird.sourceforge.net and click the Resources item
> >on the main (top) menu. Try Knowledgebase and FAQ links !
> >
> >Also search the knowledgebases at http://www.ibphoenix.com
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >