On Fri, 26 Mar 1999 20:23:04 +0000, Fred T. Krogh wrote:
>responses?) The approach I mention above, i.e. looking for D entries,
>then DK entries and then DKB entries will take advantage of the indexing
>that is available, and thus should be reasonable fast?
Yes. Hard to think of a faster way, especially since it will only be at
most 3 "sets". Combined in one query you'd also eliminate duplicates,
i.e. WHERE x='D' OR x='DK' OR x='DKB'.
An alternative would be to limit the mail categories to e.g. 32 and use
5 bits, limit the second set to 5 bits and the third level to 6 bits.
In each case, the value 0 mens no restriction. You or course need to
translate categories to a number, rather than a letter (you need to
encode the categories anyway (i.e. it doesn't matter if crypto => 'C'
or crypto => 10).
Thus, if D1 = 10, K2= 3, and B(level 3)=2, you'd have 10,3,2 and you'd
look for x=(10 << 11) OR x=(10 << 5 + 3 )<< 6 OR x=(10<<5 + 3)
<<6 + 2.
The time taken for those computations is negligable, but all your
records would be indexed on a single 32-bit integer rather than a
CHAR(8). To me this is simple enough that I'd always do it, YMMV, and
access may be so fast that the gain is negilgable as well.
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
