Hi David,

Sorry, that's not what I thought you were suggesting.

Do we really want software that builds, indexes, and maintains a new table for each new filter? There could be hundreds of them which come and go over time.

I should emphasize that the filters are meant to be very dynamic - administrators write their own on the fly, and put them in the tblRoleAccessSelectFilter table when they want them assigned to various roles. At that point the security table tblRoleAccessSelect is automatically re-computed for the benefit of those users who are assigned roles attached to the new filter.

Regarding efficiency, take the extreme example of filtering those people whose ID is the product of two prime numbers. If 50 people use that filter, do we really want the server doing that kind of computation for each of them every time they sign on? With the fixed set, it's only done once for each role using that filter.

Still, I believe that filters silently built for each user at run time is an excellent approach (I think Oracle does something along those lines). I just don't know about the relative efficiency of each method.