Используете сбор данных изменений для небольших настольных приложений?

Question

У моего нового клиента есть небольшое приложение для базы данных VB / Access, написанное в 2002 году, которое он хочет переписать, чтобы оно было более современным и поддерживало новые функции, которые он давно хотел. Итак, я собираюсь преобразовать его для использования C # .NET 2008 и SQL Server Express 2008 на локальном компьютере с возможностью масштабирования для использования WCF и SQL Server 2008 на удаленном сервере.

Одна из новых функций, которые его интересуют, - ведение и создание отчетов о полной истории изменений данных за определенный период времени. В прошлом я делал это с помощью триггеров и хранимых процедур, и это боль в @! # $.

В последнее время у меня возникла проблема с функциями захвата данных изменений в SQL Server 2008. Во время моего начального часа игры с ним я понял, что он создает задание в агенте SQL, которое по умолчанию выполняется каждые 5 секунд. Также кажется, что мне нужно немного больше боли, когда мне нужно изменить схему захваченных таблиц. Кроме этого, это кажется гораздо проще для реализации, чем мой оригинальный метод. Итак, это мои вопросы:

1. Является ли это избыточным для небольшого настольного приложения, которое может или не может в конечном итоге перейти на удаленный сервер?
2. Чего мне ожидать в плане производительности? Поскольку размер его базы данных увеличивается, я получу от него больше звонков, говорящих о том, что его компьютер работает медленно?
3. Существуют ли какие-либо другие ошибки с CDC, о которых мне следует знать от тех, кто в настоящее время использует их в производстве?
4. Есть ли у кого-нибудь ссылки на свои любимые способы отслеживания изменений во времени, которые могли бы лучше подойти для небольших настольных приложений?

Спасибо

Марк

Answer 1

CDC доступен только в выпуске SQL Server Enterprise. так что если у вас есть экспресс, вы не можете его использовать, и вам придется остаться с триггерами.

Answer 2

Я использовал свою собственную систему отслеживания изменений, используя столбец XML в моей таблице изменений, что делает ее более гибкой. Также делает триггер довольно общим.

Предполагается, что у вас уже есть триггеры для создания строк аудита, а в исходной таблице есть столбец с именем «Версия» типа ROWVERSION:

INSERT INTO [Changes].Sites
(
    SiteID,
    Operation,
    Version,
    ModifiedOn,
    DataChange
)
SELECT
    IsNull( I.SiteID, D.SiteID ),
    CASE
        WHEN D.[Version] IS NULL      AND I.[Version] IS NOT NULL  THEN 'I'
        WHEN D.[Version] IS NOT NULL  AND I.[Version] IS NOT NULL  THEN 'U'
        WHEN D.[Version] IS NOT NULL  AND I.[Version] IS NULL      THEN 'D'
        ELSE '?'
    END,
    IsNull( I.Version, D.Version ),
    SysDateTimeOffset(),
    (
        SELECT
            [Deleted] = ( SELECT * FROM deleted D1 WHERE D1.SiteID = D.SiteID FOR XML PATH(''), TYPE ),
            [Inserted] = ( SELECT * FROM inserted I1 WHERE I1.SiteID = I.SiteID FOR XML PATH(''), TYPE )
        FOR XML PATH('Changes')
    )
FROM deleted D
FULL JOIN inserted I
    ON D.SiteID = I.SiteID

Единственная вещь в этом запросе, специфичная для моей таблицы, это первичный ключ. Генерация шаблона для создания этих запросов будет довольно простой (можно даже сделать это в SQL, используя sys.tables и т. Д.).

Answer 3

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