Alan McDonald wrote:

> you said above that store_no is a PK - how can you deliver DISTINCT pk
> values unless it is just select pkfield from table?

No, he said that (SKU, STORE_NO) constitutes a PK. The GROUP BY 1 is
obviously a typo, probably because he was experimenting with variations
of the query to see what the results would be. He meant GROUP BY STORE_NO.

What's the big mystery? He has a large (many records) table with a
column containing a rather small value set and he wants to retrieve this
value set.

Yes, he could put this value set in a separate table and ref that with
an FK, but that would kind of implicate that he knows the value set
beforehand. If that were the case, why would he want to run this query
in the first place?

My guess is that if he were to solve it that way, he would probably have
to redeign parts of his application, simply to make it work reasonably
well on FB.

This is the kind of problem I think many novice FB users are
experienceing. The fact is that while FB seems to perform very well in a
wide range of applications, it seems to require a lot more clever
thought from the application developer to avoid a lot of performance
pitfalls.

IMO this is probably one of the largest reasons FB is not more popular
than it is. A novice DB developer will try it out, find that in some
common cases FB performance sucks, and quit. The fact that the bad
performance was caused by the way he did his tests is irrelevant. The
engine should be able to do a better job to avoid these performance
bottlenecks.

I'm not saying that FB is louse or badly written - far from it. But the
FB development team should be aware that this is a real problem and you
should give it a lot of thought, instead of bashing guys like buppcpp
and misreading his posts.

Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64