timestamp

Обнаружил полную бесполезность этого поля и типа данных при работе с репликацией и копированием. Оно не решает задачи определения какое изменение произошло последним. Кроме этого имеет глупое ограничениеЖ нельзя использовать к этому полю default, которое смогло бы решить вышепоставленную задачу.

timestamp - плод больного воображения программистов.

Комментарии

Изображение пользователя st.

Да

И поэтому timestamp начиная с 2008 объявлен "тяжелым наследием тоталитарного прошлого", используй тип rowversion.

Изображение пользователя ipanshin.

ну да, а то, что

ну да, а то, что было до 2008 сервера можно и похерить. А новый тип он что?
Читаю
rowversion is the synonym for the timestamp data type and is subject to the behavior of data type synonyms.
бла-бла-бла
Думаю, что он не ответит на вопрос какое изменение самое позднее среди списка баз. Тут нужен twinkle.

Изображение пользователя ipanshin.

Нужно не только

Нужно не только время. Нужна автоматическая фиксация времени изменения, что и присутствовало в timestamp. datetime2 поддерживает изменение автоматом? Хотя я могу использовать все что угодно, добавив в обработчик put , изменения временного поля. Плата за это - дополнительный update.

Изображение пользователя st.

Триггер

Триггер AFTER из пары строк, однотипный, т.е. можно реализовать одним макросом или легко сгенерировать.

Изображение пользователя ipanshin.

Нет, sorry, но

Нет, sorry, но триггер в рамках репликации не есть хорошо. Можно сразу обратиться к реализации microsoft и увидеть, что таблицы базы увешаны триггерами, которые, кстати, состоят не из пары строк зачастую. Отладка работы в такой базе также составляет проблему. Кроме этого, таблицы исковерканы доп.колонками типа rowguidcol. Такое чувство, что база завшивела, даже хочется чесаться. По отдельности вроде все мизерное, а в сумме дает большую величину. Я оцениваю эти затраты в 100%. Как в плане увеличения размера базы, так и ее времени отклика.

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

Сегодня практически завершил синхронизацию объектов на базе модели "источник - приемник" в рамках nexus для баз данных. Добавил в настройку копирования элементы настройки разрешения конфликтов. Так что теперь можно синхронизировать данные между двумя базами ручками простой операцией drug&drop. Если необходимо выполнять это по расписанию, то агент, можно вставить в расписание, указав ему папку, содержимое которой он будет синхронизировать. Естественно в папке приемника должен быть документ настройки копирования или синхронизации. В принципе можно использовать и nexus клиента как cron.

В 2008 появилась

В 2008 появилась новая фича - Change Tracking.
С новыми разработками теперь проблем не будет.
Старые - переводить на 2008 и подключать Change Tracking.

Изображение пользователя st.

На вид

На вид - сырая фишка, есть явные ограничения, можно представить себе сколько неявных и прочих камней под водой, пока не хочется завязываться. Существует только в enterprise-версии.

Я ее использую

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

Какие ограничения ты заметил?

Изображение пользователя st.

Собсно

Собсно претензии аналогичные таковым к репликации - раз настроил, после этого "ничего не трогай, ничего не меняй". Тока репликации уже 15 лет, механизм более-менее отладили.
Если, например, таблица разделена (partitioned), то операции с разделами при включенном отслеживании изменений производить нельзя (SWITCH PARTITION).
Нужна enterprise-версия сиквела, что для средних клиентов не подойдет.
Снапшот-изоляция должна быть включена.
Период сброса "хвоста" изменений задается явно, типа "храним за последние 3 дня". В задаче, когда надо хранить измениения, пока не синхронизируются все клиенты это не прокатывает никак. То есть надо включать какие-то большие сроки, недели, отключать автосброс и делать сверху разработку.
Непонятны накладные расходы по производительности, а управлять хранением истории, например, накапливая ее рядом в узкой табличке, ты не можешь.

Собственное решение отслеживания изменений не настолько уж сложное, зато максимально гибкое и управляемое.