Many pubs or single pub with dynamic filters ??

Hello...
Some background: We have merge replication set up between SQL 2000 and
mobile devices running SQL Mobile. Each of our customers has a unique
customer id and currently we have a separate publication for each one...that
has a static filter such as "WHERE CustomerID = 12345". And on each device,
it subscribes to its own publication...based on the Customer ID.
What I am thinking about...in the near future, as our customer base grows,
is that we'll be faced with maintaining lots of Publications on the server -
one for each Customer ID.
So, would it be better to have a single publication that has dynamic
filters...based on the HostName property...which I'd set in code on the
device (based on the Customer ID) or keep things the way we have them now?
I am mostly concerned about replication/synchronization performance between
the server and the mobile devices...some of which use GPRS for connectivity.
I don't want to sacrifce any performance gains, if there are any, by having
lots of publications.
thanks for any thoughts.
- will
Here are the issues that you need to consider when moving to a single
publisher model:
1. Concurrency: syncing multiple subscribers at the same time is not
optimized in SQL2000, which will end up serializing the merge process. In
SQL2005, performance is greatly improved by allowing multiple subscribers to
sync at the same time.
2. Partitioning: When a subscriber with a given ID syncs, SQL2000 will scan
the publisher's articles for changes pertaining to that subscriber. This
process has its performance implications for large publication with large
number of changes. In SQL2005, this issue was also addressed by the use of
partition groups.
Regards,
Rafik
This posting is provided "AS IS" with no warranties, and confers no rights.
"dw" <dw@.discussions.microsoft.com> wrote in message
news:7730CDFB-81A8-437B-80A5-C5B0131814B9@.microsoft.com...
> Hello...
> Some background: We have merge replication set up between SQL 2000 and
> mobile devices running SQL Mobile. Each of our customers has a unique
> customer id and currently we have a separate publication for each
> one...that
> has a static filter such as "WHERE CustomerID = 12345". And on each
> device,
> it subscribes to its own publication...based on the Customer ID.
> What I am thinking about...in the near future, as our customer base
> grows,
> is that we'll be faced with maintaining lots of Publications on the
> server -
> one for each Customer ID.
> So, would it be better to have a single publication that has dynamic
> filters...based on the HostName property...which I'd set in code on the
> device (based on the Customer ID) or keep things the way we have them now?
> I am mostly concerned about replication/synchronization performance
> between
> the server and the mobile devices...some of which use GPRS for
> connectivity.
> I don't want to sacrifce any performance gains, if there are any, by
> having
> lots of publications.
> thanks for any thoughts.
> - will
|||Hi...
Thanks for the quotes from the BOL. However, we cannot move to SQL 2005 for
a while...so these won't help me now and for the near future.
Any other thoughts regarding my question...which is simply, "Is it better to
have one publication that multiple subscribers sync with...using their
Customer ID in the filtering of the data, or is it better to have multiple
publications that are unique to each subscriber?" And, when I ask which is
"better", I mean from a replication/synchronization performance aspect...from
the subscriber's end of the things.
thanks
- will
"Rafik Robeal" wrote:

> Here are the issues that you need to consider when moving to a single
> publisher model:
>
> 1. Concurrency: syncing multiple subscribers at the same time is not
> optimized in SQL2000, which will end up serializing the merge process. In
> SQL2005, performance is greatly improved by allowing multiple subscribers to
> sync at the same time.
>
> 2. Partitioning: When a subscriber with a given ID syncs, SQL2000 will scan
> the publisher's articles for changes pertaining to that subscriber. This
> process has its performance implications for large publication with large
> number of changes. In SQL2005, this issue was also addressed by the use of
> partition groups.
>
> Regards,
> Rafik
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "dw" <dw@.discussions.microsoft.com> wrote in message
> news:7730CDFB-81A8-437B-80A5-C5B0131814B9@.microsoft.com...
>
>
|||I have found that static filters perform better than dynamic ones. Obviously
however, there is more management (DBA work) to do.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Thanks for the reply and info. That is what I was thinking...that the
performance would be better forindividual publications based on a static
filter...but figured I should toss this question out to the group, in case I
was missing something.
thanks
- will
"Paul Ibison" wrote:

> I have found that static filters perform better than dynamic ones. Obviously
> however, there is more management (DBA work) to do.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>