![[info]](http://stat.livejournal.com/img/syndicated.gif){kind=small}
timestamp
Опубликовано ipanshin в вт, 10/11/2009 - 08:58.
Обнаружил полную бесполезность этого поля и типа данных при работе с репликацией и копированием. Оно не решает задачи определения какое изменение произошло последним. Кроме этого имеет глупое ограничениеЖ нельзя использовать к этому полю default, которое смогло бы решить вышепоставленную задачу.
timestamp - плод больного воображения программистов.
- Блог пользователя ipanshin
- Добавить комментарий
- Просмотров 586
Да
И поэтому timestamp начиная с 2008 объявлен "тяжелым наследием тоталитарного прошлого", используй тип rowversion.
ну да, а то, что
ну да, а то, что было до 2008 сервера можно и похерить. А новый тип он что?
Читаю
rowversion is the synonym for the timestamp data type and is subject to the behavior of data type synonyms.
бла-бла-бла
Думаю, что он не ответит на вопрос какое изменение самое позднее среди списка баз. Тут нужен twinkle.
В 2008 появилась
В 2008 появилась новая фича - Change Tracking.
С новыми разработками теперь проблем не будет.
Старые - переводить на 2008 и подключать Change Tracking.
На вид
На вид - сырая фишка, есть явные ограничения, можно представить себе сколько неявных и прочих камней под водой, пока не хочется завязываться. Существует только в enterprise-версии.
Я ее использую
Я ее использую в системе автоматического формирования заданий на обработку кубов. Пока ни каких граблей не обнаружили. Но используем только для анализа в каких таблицах данные изменились, без анализа что именно (это будет во второй версии, которая будет поддерживать обработку разделов).
Какие ограничения ты заметил?
Собсно
Собсно претензии аналогичные таковым к репликации - раз настроил, после этого "ничего не трогай, ничего не меняй". Тока репликации уже 15 лет, механизм более-менее отладили.
Если, например, таблица разделена (partitioned), то операции с разделами при включенном отслеживании изменений производить нельзя (SWITCH PARTITION).
Нужна enterprise-версия сиквела, что для средних клиентов не подойдет.
Снапшот-изоляция должна быть включена.
Период сброса "хвоста" изменений задается явно, типа "храним за последние 3 дня". В задаче, когда надо хранить измениения, пока не синхронизируются все клиенты это не прокатывает никак. То есть надо включать какие-то большие сроки, недели, отключать автосброс и делать сверху разработку.
Непонятны накладные расходы по производительности, а управлять хранением истории, например, накапливая ее рядом в узкой табличке, ты не можешь.
Собственное решение отслеживания изменений не настолько уж сложное, зато максимально гибкое и управляемое.
Если нужно время
Если нужна дата и время изменения, то введен тип datetime2
Нужно не только
Нужно не только время. Нужна автоматическая фиксация времени изменения, что и присутствовало в timestamp. datetime2 поддерживает изменение автоматом? Хотя я могу использовать все что угодно, добавив в обработчик put , изменения временного поля. Плата за это - дополнительный update.
Триггер
Триггер AFTER из пары строк, однотипный, т.е. можно реализовать одним макросом или легко сгенерировать.
Нет, sorry, но
Нет, sorry, но триггер в рамках репликации не есть хорошо. Можно сразу обратиться к реализации microsoft и увидеть, что таблицы базы увешаны триггерами, которые, кстати, состоят не из пары строк зачастую. Отладка работы в такой базе также составляет проблему. Кроме этого, таблицы исковерканы доп.колонками типа rowguidcol. Такое чувство, что база завшивела, даже хочется чесаться. По отдельности вроде все мизерное, а в сумме дает большую величину. Я оцениваю эти затраты в 100%. Как в плане увеличения размера базы, так и ее времени отклика.
Система же остается работоспособной, если управленческие затраты не превышают 30 процентов.
Сегодня практически завершил синхронизацию объектов на базе модели "источник - приемник" в рамках nexus для баз данных. Добавил в настройку копирования элементы настройки разрешения конфликтов. Так что теперь можно синхронизировать данные между двумя базами ручками простой операцией drug&drop. Если необходимо выполнять это по расписанию, то агент, можно вставить в расписание, указав ему папку, содержимое которой он будет синхронизировать. Естественно в папке приемника должен быть документ настройки копирования или синхронизации. В принципе можно использовать и nexus клиента как cron.