Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Двухсторонняя синхронизация данных.  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18326
Реализовать на timestamp(rowversion) или на CHANGE_TRACKING. Принцип у них один: версия строки.

Вот логический пример.
Два сервера A и B.
Одна таблица.
CREATE TABLE T (PK int , value int, stamp timestamp)

Сервер А. Создаем запись. A.t.stamp = 1
Сервер B забирает запись себе A.t.where stamp>0. Устанавливает значение @Astamp = 1. B.T.stamp = 1
Сервер A обновляет запись у себя B.t.where stamp>0. Устанавливает значение @Bstamp = 1. A.T.stamp = 2
Сервер B обновляет запись у себя A.t.where stamp>1. Устанавливает значение @Astamp = 2. B.T.stamp = 2
Сервер A обновляет запись у себя B.t.where stamp>1. Устанавливает значение @Bstamp = 2. A.T.stamp = 3

И так до бесконечности (сама синхронизация увеличивает версию строки).

timestamp и CHANGE_TRACKING_CURRENT_VERSION увеличиваются, даже если данные по факту не поменялись(Update T set value = value).

Получается надо делать так
Update T set value = @newValue where value <> @newValue
Это не очень удобно, но это правильный подход?

Получится:
Сервер А. Создаем запись. A.t.stamp = 1
Сервер B забирает запись себе where A.t.stamp>0. Устанавливает значение @Astamp = 1. B.T.stamp = 1
Сервер A читает запись у себя where B.t.stamp>0. Устанавливает значение @Bstamp = 1. A.T.stamp = 1(запись не обновилась)
Сервер B не ничего не увидет where A.t.stamp>1

+ PS
К примеру на MySQL timestamp не меняется при Update, если не поменялись данные по факту. Что мне кажется логичней и удобней.
8 июн 17, 09:52    [20548995]     Ответить | Цитировать Сообщить модератору
 Re: Двухсторонняя синхронизация данных.  [new]
iap
Member

Откуда: Москва
Сообщений: 46983
Deff,

поле типа timestamp получает своё значение от сервера.
Это значение одно на всю базу данных.
Так что "устанавливает значение" - это как?
8 июн 17, 10:18    [20549078]     Ответить | Цитировать Сообщить модератору
 Re: Двухсторонняя синхронизация данных.  [new]
aleks2
Guest
Deff
Получается надо делать так
Update T set value = @newValue where value <> @newValue
Это не очень удобно, но это правильный подход?



Надо федя, надо.
Ибо это еще и быстрее.
И журнал экономит.

Любое "изменение" - это запись на диск.
А сравнение - это так... ничего.
8 июн 17, 10:39    [20549179]     Ответить | Цитировать Сообщить модератору
 Re: Двухсторонняя синхронизация данных.  [new]
invm
Member

Откуда: Москва
Сообщений: 9351
Deff
Реализовать на timestamp(rowversion) или на CHANGE_TRACKING.
Штатная репликация чем не устроила?
8 июн 17, 11:30    [20549380]     Ответить | Цитировать Сообщить модератору
 Re: Двухсторонняя синхронизация данных.  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18326
iap
Deff,

поле типа timestamp получает своё значение от сервера.
Это значение одно на всю базу данных.
Так что "устанавливает значение" - это как?
Имеется ввиду изменяя запись - устанавливается значение timestamp.


aleks2
Deff
Получается надо делать так
Update T set value = @newValue where value <> @newValue

Это не очень удобно, но это правильный подход?



Надо федя, надо.
Ибо это еще и быстрее.
И журнал экономит.

Любое "изменение" - это запись на диск.
А сравнение - это так... ничего.
Понятно. Буду.

invm
Deff
Реализовать на timestamp(rowversion) или на CHANGE_TRACKING.
Штатная репликация чем не устроила?
Штатная есть двухсторонняя? Как там резолвить конфликты?

Да и потом второй сервер не MSSQL.
И CHANGE_TRACKING вполне хорошая штука.
8 июн 17, 12:59    [20549823]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить