Working Around Filtering Problems in Merge Replication

Question

I am in the process of defining filters on a merge replication publication for our database.

The problem I am coming up against is that merge replication has these rules, I don't like to call them limitations because I can understand the purpose.

1) When creating an article filter you cannot include a subquery, or at least you shouldn't. If you do then it will appear to work the first time you sync, but if something changes in the subquery table the filter will not be re-evaluated.

2) When using a join filter you can only join two tables together.

The problem I am coming across is that the relationships in our database are more complicated than that. For instance here is one of our relationships,

user <- regions selected <- STREET LIGHTS -> settings (are we syncing street lights) -> user

Here is an example table structure to explain the above in more detail,

User Table,

Id    Username
1     petermc

UserRegion Table, (think of this as a security table, which region is a particular user allowed to see)

Id    UserId    RegionId
1     1         2
1     2         4

SyncSetting Table,

Id    UserId    Table
1     1         StreetLight

Region Table (this is just a look up table to show some example regions)

Id    Region Name
1     North Auckland
2     South Auckland
3     Central Auckland
4     Great Barrier Island

Road Table,

Id    RegionId    Name
1     1           Rosedale Rd
2     1           North Shore Rd

StreetLight Table

Id    RoadId    Last Replaced
1     1         2012-05-01
2     1         2009-06-03
3     2         2001-06-08

So in this case if I wrote out a select statement to apply my filtering for petermc it would look like this,

select * from StreetLight where
roadId in (select Id from Road where RegionId in (select regionId from UserRegion where userid = 1))
and exists (select 1 from syncsetting where userid = 1 and [table] = 'StreetLight')

So I am doing two things there. First filtering based on region to reduce a very large table into a smaller more manageable subset.

The second is specifying whether the subscriber is interested in the StreetLight table at all. If they are not then the subscriber should have an empty StreetLight table. This part is important because the publication will have a large number of tables in it, so it doesn't make sense to include stuff that the subscriber is not going to use.

Our biggest database has millions of records in some tables, and there will be a moderate amount of updates of these records too. We must get this filtering correct. The option to not filter those tables is not feasible.