Обязательно ли перепрыгивать через серверы - это плохая практика программирования? - PullRequest
2 голосов
/ 23 февраля 2010

У меня есть система, созданная так, что пользователь в одном из наших мест и на своем сервере вставляет запись. Эти данные затем реплицируются на центральный сервер. Пользователи, работающие на центральном сервере, могут редактировать эту запись, что означает, что я должен заблокировать возможности редактирования в том месте, где была создана запись.

Однако я хотел бы, чтобы создатель записи мог редактировать ее, поэтому я думаю о перенаправлении их на серверы для редактирования записи на центральном сервере. Это плохая практика и почему ??

Причина, по которой я разрешаю редактировать только одну из копий записи, заключается в том, чтобы предотвратить ее копирование при репликации .....

МЫ также рассматриваем возможность двунаправленной репликации.

Ответы [ 2 ]

1 голос
/ 25 февраля 2011

Это неплохая практика.Не уверен, что это имеет большой смысл (для меня), но вы могли бы сделать это, не вызывая проблем, кажется.

Но вам следует подумать, почему вы вообще используете репликацию.Какими бы ни были ваши причины, посмотрите, как они подходят для подключения к вашему центральному серверу.Поскольку основной целью репликации является предоставление вам возможности работать без подключения к центральному серверу (кроме случаев, когда вы синхронизируете)по-другому.

1 голос
/ 23 февраля 2010

В прошлой работе мы использовали репликацию транзакций SQL Server с центрального издателя на три сервера подписчиков. Задержка была такой, что пользователи требовали (и получали) возможность обновлять реплицированные данные на серверах назначения, что приводило к сбоям / конфликтам репликации.

Похоже, что общий дизайн использования репликации, возможно, не учитывал желание (или необходимость) непосредственно обновлять подписчика. Можно ли на этом сделать быструю доску с ключевыми игроками?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...