MS SQL синхронизация / Timestamp

← →
Ellisium © (2014-11-11 19:26) [0]

Верен ли нижеприведенный алгоритм синхронизации удаленной БД с центральной БД?

1) имеем запомненное с предыдущей синхронизации значение @oldTimeStamp (в первый раз равное нулю) для удаленной таблицы
2) определяем максимальный timestamp в удаленной таблице типа:

select @newTimeStampmax=max(timestamp) from MyTable

3) делаем выборку всех записей в удаленной таблице: ... where timestamp >= @oldTimeStamp and <= @newTimeStamp

Записи, попавшие под условие - синхронизируем в центральную базу.
Отдельная песня - удаление записей.

4) запоминаем @newTimeStamp для этой таблицы в пункт 1) как @oldTimeStamp для следующей синхронизации.

Есть ли недостатки?

← →
Ellisium © (2014-11-11 19:30) [1]

Ну в принципе я вижу один подводный камень в виде вопроса. После того, как выполнен запрос:

select @newTimeStamp=max(timestamp) from MyTable

может ли в таблице появиться запись, у которой timestamp будет меньше или равен @newTimeStamp?

← →
Ega23 © (2014-11-11 19:46) [2]

> Есть ли недостатки?

http://technet.microsoft.com/ru-ru/library/bb726005%28v=sql.110%29.aspx

> После того, как выполнен запрос:

По-идее, эти дела надо в snapshot-транзакции у источника делать.

← →
Ellisium © (2014-11-11 19:49) [3]

> http://technet.microsoft.com/ru-ru/library/bb726005%28v=sql.
> 110%29.aspx

Эта статья не противоречит моему алгоритму, но они и не подтверждает основной вопрос, сформулированный мной в Ellisium © (11.11.14 19:30) [1]

← →
Ega23 © (2014-11-11 20:19) [4]

Скажем так. Задачи связанные с синхронизацией времени - наиболее муторные. В частном случае твой алгоритм будет работать. В общем - можно придумать ситуацию, когда нет.
Именно это я и имел ввиду, когда о недостатках писал.
Тут надо внимательно на исходные условия смотреть. Может синхронизируемая таблица небольшая, тогда имеет смысл её вообще полностью перенести например. Или сделать составную искусственную метку guid + rowversion. Или ещё что-нибудь.
Одного timestamp, ИМХО, будет мало. Вдобавок я уже не помню, он в UTC идёт или нет, а это тоже проблема.

← →
Кщд © (2014-11-11 21:11) [5]

>Ellisium © (11.11.14 19:26)
учитывая транзакционность и часовые пояса, ваше решение не будет работать, в общем случае

← →
TohaNik © (2014-11-11 21:15) [6]

Опять же ИМХО. Блокировки нужны. Сыылку не читал.

← →
Кщд © (2014-11-11 21:16) [7]

вдогоночку: не надо выдумывать велосипед при наличии штатных средств
тем паче, не понимая основ РСУДБ

← →
Кщд © (2014-11-11 21:17) [8]

*РСУБД))

← →
Ega23 © (2014-11-11 21:21) [9]

> не надо выдумывать велосипед при наличии штатных средств

Штатные средства, порой, тоже ещё с теми загогулинами бывают.
К примеру, в том же MSSQL (2000 - это точно, как в новых - не знаю) тип datetime имел дискрет в 3 миллисекунды.

← →
TohaNik © (2014-11-11 21:32) [10]

И иногда текущее время не совсем текущее...

← →
Ega23 © (2014-11-11 21:41) [11]

> И иногда текущее время не совсем текущее...
>

Синхронизация между разными машинами - вообще отдельная и очень больная тема.

← →
картман © (2014-11-11 21:46) [12]

> Ega23 © (11.11.14 20:19) [4]

> он в UTC идёт или нет

а что такое UTC? Или что у них там написано:
Типы данных rowversion и timestamp являются синонимами. ... Тип данных rowversion является увеличивающимся числом и не основан на дате или времени
?

← →
TohaNik © (2014-11-11 21:54) [13]

> Ellisium © (11.11.14 19:26)
> Верен ли нижеприведенный алгоритм синхронизации удаленной
> БД с центральной БД?

> Ega23 © (11.11.14 21:41) [11]
> > И иногда текущее время не совсем текущее...> Синхронизация
> между разными машинами - вообще отдельная и очень больная
> тема.

На радостях отпуска всяко не внимательно читаю.
Но даже при центральной БД, иногда текущее время не совсем текущее...;)

← →
Ega23 © (2014-11-11 21:55) [14]

> а что такое UTC?

https://ru.wikipedia.org/wiki/%D0%92%D1%81%D0%B5%D0%BC%D0%B8%D1%80%D0%BD%D0%BE%D0%B5_%D0%BA%D0%BE%D0%BE%D1%80%D0%B4%D0%B8%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%B2%D1%80%D0%B5%D0%BC%D1%8F

> Типы данных rowversion и timestamp являются синонимами

Я вот тоже удивился, честно говоря.

← →
картман © (2014-11-12 11:58) [15]

> Ega23 © (11.11.14 21:55) [14]

ну я и спрашиваю, какое отношение число, не относящееся к дате, имеет отношение к UTC? Или справка кривая?))

← →
Кщд © (2014-11-12 13:46) [16]

>Ega23 © (11.11.14 21:21) [9]
>Штатные средства, порой, тоже ещё с теми загогулинами бывают.
согласен абсолютно
но это повод разобраться со штатными средствами, а не "пилить" собственную нерабочую синхронизацию а-ля "select @newTimeStamp=max(timestamp) from MyTable"

← →
Ega23 © (2014-11-12 14:19) [17]

> ну я и спрашиваю, какое отношение число, не относящееся
> к дате, имеет отношение к UTC? Или справка кривая?))

ХЗ, если честно. Я вчера прочитал и очень удивился.

← →
TohaNik © (2014-11-12 14:43) [18]

> но это повод разобраться со штатными средствами

Там тоже люди...
А дата + время нельзя, наверное, для случки использовать, даже если с поясами разобрались.Там ИМХО даже время обработки кода гуляет.

← →
Труп Васи Доброго © (2014-11-12 15:07) [19]

> может ли в таблице появиться запись, у которой timestamp
> будет меньше или равен @newTimeStamp?

А твоё изобретение сработает, когда запись не добавят или изменят, а удалят?

← →
TohaNik © (2014-11-12 18:32) [20]

> Отдельная песня - удаление записей.

> А твоё изобретение сработает, когда запись не добавят или
> изменят, а удалят?

Нельзя удалять.

← →
Труп Васи Доброго © (2014-11-13 11:38) [21]

> Нельзя удалять.

А как же ошибки? А срабатывание триггеров? Затея с привязкой ко времени гнилая изначально. Это проколется либо на рассинхроне времени на машинах, либо на записях, изменённых во время синхронизации, либо ещё как. Проще записывать по порядку все SQL команды, приходящие к БД и при синхронизации передавать их же на дубликат.

← →
TohaNik © (2014-11-13 12:59) [22]

> А как же ошибки? А срабатывание триггеров?

ну опять же ИМХО :) . Ошибки выявлять надо до записи в базу, иначе это уже и не совсем ошибка.
Тригеры в коде бизнес-процесса зло, и знать о них может только разработчик, для удовлетворения своих, ни кому не нужных целей.

← →
Труп Васи Доброго © (2014-11-13 13:30) [23]

> Тригеры в коде бизнес-процесса зло

Не знаю что такое "бизьнесъ-процессъ", извините, но отсутствие триггеров в БД на мой взгляд, должно означать увольнение архитектора этой БД однозначно. И как же у вас в БД организована целостность? Руками все логические связи отслеживаете и изменения вносите? Тогда зачем вообще БД нужна? Бумага и три слоя копирки, вот и будет синхронизация данных, причём мгновенная.

← →
Труп Васи Доброго © (2014-11-13 13:38) [24]

> Ошибки выявлять надо до записи в базу

Это как? Примеры:
1) Продали товар, занесли информацию в базу, потом покупатель товар вернул (совсем или обменял на другой).
2) Приняли товар на склад по накладной, занесли в БД, в одном из 100500 ящиков оказались "носки вместо трусов", надо делать возврат поставщику (с уменьшением стоимости, изменением договора и т.д. либо с заменой)
И таких вариантов море морьское. Как ты, о знаток "бизнесс-процессов" выявишь такие ошибки ДО внесения в БД???

← →
TohaNik © (2014-11-13 13:41) [25]

Да тут уже не раз тема ключей поднималась. И тригерры не хаю. Не надо просто их отрабатывание связывать с действиями пользователя, хотя бы визуально.

← →
Труп Васи Доброго © (2014-11-13 13:51) [26]

> Не надо просто их отрабатывание связывать с действиями пользователя,
> хотя бы визуально.

Э.......э........ъ..?
??? КУДА ???

← →
Труп Васи Доброго © (2014-11-13 13:53) [27]

> Не надо просто их отрабатывание связывать с действиями пользователя,
> хотя бы визуально.

Прочитал ещё несколько раз... Только два вопроса возникло: Где грибочки брал и сколько стоят?

← →
TohaNik © (2014-11-13 13:54) [28]

> "носки вместо трусов", надо делать возврат поставщику (с
> уменьшением стоимости, изменением договора и т.д. либо с
> заменой)

И причем тут триггеры?

забористая трава

> И причем тут триггеры?

Потому что "сторно"!

Я гидроусилитель руля, АБС и климат-контроль не хаю. Не надо просто их отрабатывание связывать с действиями пользователя, хотя бы визуально.
Аналогия ясна?

Да сторно, уже как бы отмена. и при чем тут триггеры?

по факту... :)

> как бы отмена

Правильно, "как бы"! Ведь перед тем, как удалить запись о "трусах" на складе надо проверить, а не отправили ли этот ящик в магазин и не продали. Если не продали, то сформировать заявку на возврат, забронировать место в транспорте, оформить накладную на возврат на склад и т.д и т.п. То есть проверить на возможность удаления, сделать все необходимые перед удалением действия, а уж только потом удалять. Ты предлагаешь всё это делать вручную? Это работа триггеров.

Да удалять ничего не нужно!

Ребят, хотелось бы услышать мнение людей, которые работали с Ms sql и которые в частности хорошо понимают как работает timestamp. Особенно интересует вопрос озвученный в [1]

Я особо не работал! Нельзя... Лень- timestamp,
Ну так и расскажи, или покритикуй, или наоборот чинавыворот?.
Репликации идеальной просто не бывает.

> Ну так и расскажи

что рассказать? У меня у самого вопросы, я поэтому тему создал.

Просто тут столько понаписали, а явно видно, что люди даже минимально не знают, что такое timestamp в ms sql. А половина, видимо, даже и вопроса не прочитала.

Главным остается вопрос в [1]:

После выполнения запроса:

select @newTimeStamp=max(timestamp) from MyTable

Может ли в MyTable появиться запись, у которой timestamp будет меньше или равен @newTimeStamp?

> [38] Ellisium © (13.11.14 19:09)
> а явно видно, что люди даже минимально не знают, что такое timestamp в ms sql

Знают тут люди, а понаписали потому, что ты что-то неправильное хочешь сделать.

> После выполнения запроса:select @newTimeStamp=max(timestamp)
> from MyTableМожет ли в MyTable появиться запись, у которой
> timestamp будет меньше или равен @newTimeStamp?

Может, он не для этого.
Блокировки нужны... ИМХО

MS SQL синхронизация / Timestamp Найти похожие ветки