21.08.2015 12:14, 'Louis van Alphen' wrote:
Dmitry thanks for the insight. This actual puts FB in quite a different
light. I have used FB since IB 5 and is my DB of choice. However this issue
may prove quite problematic.
It does not cover all cases with views, only the ones when you need to
21.08.2015 13:58, 'Louis van Alphen' wrote:
Dmitry, re your point 4, do you mean:
create view SKIN as
select
ID,
(select NAME from COLOUR_ C where C.ID = S.COLOUR_ID)
from SKIN_ S;
Right. Not very good option when you need many lookup fields from the
same table, but could still be
Something like:
select S.*
from COLLECTION_ COLL
left join SKIN S on S.ID = COLL.SKIN_ID
where S.ID is not null
i.e. fake the left join to get the correct join order
(COLLECTION_-SKIN_-COLOUR_).
I guess that means that
select S.*
from COLLECTION_ COLL
join SKIN S on S.ID = COLL.SKIN_ID+0
Dmitry thanks for the insight. This actual puts FB in quite a different light.
I have used FB since IB 5 and is my DB of choice. However this issue may prove
quite problematic. Let me explain:
I have a large ERP class system ( currently ~400+ tables). An architectural
design choice in the
21.08.2015 10:26, 'Louis van Alphen' wrote:
Dmitry, if I then understand you correctly, if a view contains an outer join,
then FB will table scan? Is this documented somewhere so that I can read up?
It depends on a number of factors, but generally your conclusion is
correct. The problem is
20.08.2015 16:53, 'Louis van Alphen' wrote:
The same thing happens in many other queries where I use views and IMHO
I find it non-sensical. I have come to the conclusion that FB does not
choose great query plans when using views.
True, when views contain outer joins.
It is really hard to
