解决合并复制中的过滤问题

Question

我正在为我们的数据库定义合并复制发布的过滤器。

我遇到的问题是合并复制有这些规则，我不喜欢称它们为限制，因为我可以理解其目的。

1) 创建文章过滤器时不能包含子查询，或者至少不应该包含。如果你这样做，它会在你第一次同步时出现，但如果子查询表中的某些内容发生变化，则不会重新评估过滤器。

2) 使用连接过滤器时，您只能将两个表连接在一起。

我遇到的问题是我们数据库中的关系比这更复杂。例如这里是我们的关系之一，

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

这是一个示例表结构，可以更详细地解释上述内容，

用户表，

Id    Username
1     petermc

UserRegion 表，（把它想象成一个安全表，允许特定用户查看哪个区域）

Id    UserId    RegionId
1     1         2
1     2         4

同步设置表，

Id    UserId    Table
1     1         StreetLight

区域表（这只是显示一些示例区域的查找表）

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

路表，

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

路灯桌

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

所以在这种情况下，如果我写出一个 select 语句来应用我对 petermc 的过滤，它看起来像这样，

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')

所以我在那里做两件事。首先基于区域进行过滤，将非常大的表缩减为更小的更易于管理的子集。

第二个是指定订阅者是否对 StreetLight 表感兴趣。如果不是，那么订阅者应该有一个空的 StreetLight 表。这部分很重要，因为发布将包含大量表，因此包含订阅者不会使用的内容是没有意义的。

我们最大的数据库在某些表中有数百万条记录，这些记录也会有适度的更新。我们必须正确地进行这种过滤。不过滤这些表的选项是不可行的。

Answer 1

我必须发出警告。我们现在已经放弃了合并复制，我不得不建议上面的方案可能是一个主要的性能问题。

例外情况是，您需要拥有一份小型出版物，其中包含少量过滤和/或深度不深的过滤器。例如，10 - 100 篇文章可能效果很好。如果你过多地推行上述方案，你可能会遇到性能/锁定问题。

每次将记录插入顶级过滤表时，合并复制触发器都必须处理所有子表。它还将记录添加到所有子表的 MSMerge_contents 和 MSMerge_genhistory 中。您拥有的子表越多，并且其中包含大量记录，则需要的处理能力就越强。

我们遇到了 sp_MSsetupbelongs 太慢并且超时的问题。最后我们得出的结论是，我们过度推动合并复制，这项技术对我们不起作用。

这让我建议，如果开箱即用的合并复制中的过滤方案对于您的情况来说不够灵活，那么要么不过滤，要么不使用合并复制。测试测试当然，每种情况都是不同的。