Replication Architecture: Design Issue and Validation

I would like some validation on a replication architecture.
Business Context:
We are deploying a custom .NET 2 application for an retail/distribution
operation with 10 locations. The remote locations must have the ability to
continue to operate even if the central site is unavailable (these are mostly
rural locations).
Replication Requirements:
1. Corporate objects must be available to the remote locations as soon as
possible (e.g., purchase orders so that remote can receive against PO and
match line items).
2. Remote objects must be available to the corporate office and then made
available to the other remote locations as soon as possible (e.g., inventory
transfer "out").
3. All objects will be periodically processed by corporate with objects
produced via process sent to the remote locations (e.g., inventory count
checkpoints).
4. As much as possible the model should allow for a) schema changes given
that this is a v1; and b) minimal maintenance given that of 5 I.T. staff only
1 is a DBA.
Replication Architecture
A Corporate Objects shall be published to remote locations with a merge push
subscription
B Remote location Objects shall be published to the corporate office with a
merge pull subscription and then re-published to the other remote locations
via a push merge
I have a reasonable amount of SQL experience but am new to replication. I
am looking for the following feedback: a) does this design meet the business
context and application requirements; b) how do I make sure that the remote
location transactions which come in to corporate go out to the other
locations.
Thanks
Philip Neufeld, MCSE
I think you can get away with a single merge publication. If your remote
locations are well connected use push. What will happen is if branch 1 makes
a change it will go to the central location and from there be sent to all
other branches who need that copy. You can filter the data using horizontal
partitioning or row filters if you need to.
If you are using SQL 2005 schema changes can be replicated from the central
office to the branch offices.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Philip Neufeld" <PhilipNeufeld@.discussions.microsoft.com> wrote in message
news:D255F0EE-E958-4350-937F-4562AABA3C5C@.microsoft.com...
>I would like some validation on a replication architecture.
> Business Context:
> We are deploying a custom .NET 2 application for an retail/distribution
> operation with 10 locations. The remote locations must have the ability
> to
> continue to operate even if the central site is unavailable (these are
> mostly
> rural locations).
> Replication Requirements:
> 1. Corporate objects must be available to the remote locations as soon as
> possible (e.g., purchase orders so that remote can receive against PO and
> match line items).
> 2. Remote objects must be available to the corporate office and then made
> available to the other remote locations as soon as possible (e.g.,
> inventory
> transfer "out").
> 3. All objects will be periodically processed by corporate with objects
> produced via process sent to the remote locations (e.g., inventory count
> checkpoints).
> 4. As much as possible the model should allow for a) schema changes given
> that this is a v1; and b) minimal maintenance given that of 5 I.T. staff
> only
> 1 is a DBA.
> Replication Architecture
> A Corporate Objects shall be published to remote locations with a merge
> push
> subscription
> B Remote location Objects shall be published to the corporate office with
> a
> merge pull subscription and then re-published to the other remote
> locations
> via a push merge
> I have a reasonable amount of SQL experience but am new to replication. I
> am looking for the following feedback: a) does this design meet the
> business
> context and application requirements; b) how do I make sure that the
> remote
> location transactions which come in to corporate go out to the other
> locations.
> Thanks
> Philip Neufeld, MCSE