Hi David,

I may not have expressed myself clearly, so let me take another stab at it.

Using the article's simple example, we may have several dozen overlapping filters on the gateway table (eg. F1=those who work in Vancouver, F2=those who work in Chicago, F3=those who work in Oregon, F4=those who work in Canada, etc.).

If Bob is restricted to viewing those who work in Vancouver or Chicago, then we could write for him the view F1 U F2 (where U means union). If he later gets clearance for Oregon, then a new view F1 U F2 U F3 could be assigned to him. But instead, we (effectively) pass him the security table tblRoleAccessSelect where the rows he can see have already been selected (ie flagged) by the triggers. That way, we don't have to re-create views for him every time his security changes since the triggers do all the work.

(Strictly speaking, we're working with the roles assigned to users, but the idea is the same).

If I understand you correctly, you're suggesting that dynamically-generated views could be passed to users as they sign on to any app (depending on their current security in the database). That may be cleaner, actually. On the other hand, the "fixed set" approach has the advantage that you only need to decide once whether a given gateway record is captured by a given filter (which may be assigned to several concurrent users). And you still need to take distinct unions of all those filters assigned to any user if we're dynamically building views for them at run time.

I don't know which approach is more efficient.