Is jumping across servers necessarily a bad programming practice?

Question

question

Eric asked Feb 23, '10

Is jumping across servers necessarily a bad programming practice?

I have a system created that a user at one of our other locations and on their server inserts a record. That data is then replicated to a central server. Users working on the central server are allowed to edit that record which means I have to lock the editing capabilities at the location the record was created.

However, i would like the creator of the record to be able to edit it so I am thinking about redirecting them across servers to edit the record on the central server. IS that bad practice and why??

The reason I only allow editing on one of the copies of the record is to prevent it from being copied over in replication.....

WE are also considering Bi-directional replication.

sql-server-2005 t-sql replication cross-database

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2010-02-23T16:08:54Z

Tom Staab answered Feb 23, '10

It does sound like merge replication might work well for you.

To answer your initial question, I'd say ... it depends! Seriously though, here are my thoughts regarding editing data on the central server:

Pros:

single set of data
easier maintenance (no synchronizing necessary)

Cons:

potentially worse performance if central server is far away, has a slower connection or is already overloaded with users/processes
A single query joining tables between servers can often be a source of performance issues.

If your central server is local, you might not have any performance issues. I recommend trying some queries and compare performance results from each server.

1

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Matt Whitfield ♦♦ commented · Feb 23, 2010 at 06:14 PM

It depends = instant +1

2 ·

question