> >This is example SQL:
> >select TABLE_1.NAME, TABLE_2.NAME, TABLE_3.NAME, TABLE_2.LENGTH,
> >TABLE_2.LANGUAGE_ID
> >from TABLE_4
> >join TABLE_1 on TABLE_1.ID = TABLE_4.T1_ID
> >join TABLE_2 on TABLE_2.ID = TABLE_4.T2_ID
> >join TABLE_3 on TABLE_3.ID = TABLE_2.T3_ID
> >where TABLE_4.T2_ID = :T2_ID
> >
> This is a very horrible query, by the way. Not only does the
> output set have no columns from TABLE_4, but you have made TABLE_4
> the controlling table of the query. I simply do not believe this
> was ever *fast* in the BDE.
>
> From IBO's point of view (and all common sense) it is impossible
> to get column-based KeyLinks for this set. Amongst other things,
> IBO uses KeyLinks for determining the cursors it uses to set
> "windows" in datasets, to optimise the traffic between the server
> and the client. It's true to say that IBO rewards good query
> design.

Why is this 'very horrible'? True, it may be difficult to determine KeyLinks (we have not been given sufficient information to say), but the plan for this join could simply contain something like

Table_4(T2_ID_Index), Table_2(PK2_ID), Table_3(PK_3ID),Table_1(PK_1ID).

Actually, I would expect this to execute pretty fast in most circumstances. Though I think we still need more information to tell with a bit more certainty.

Set