В мире хранения данных существует различные подходы к обработке обновлений и удалений. Один интересный подход – использование мягких транзакций, при котором данные никогда не удаляются или обновляются напрямую, а вместо этого помечаются как неактивные или заменяются новыми значениями. В этой статье мы рассмотрим концепцию мягких транзакций и обсудим некоторые соображения при использовании этого подхода в SQL Server.

Что такое мягкая транзакция?

Мягкая транзакция предполагает отключение операций удаления и обновления на таблице и вместо этого использование флагов для указания статуса данных. Например, столбец-флаг с названием “IsActive” или “IsCurrent” может использоваться для пометки записи как true или false. Когда требуется обновление, добавляется новая запись с установленным флагом true, а старая запись помечается как false. Аналогично, операция удаления выполняется путем обновления флага существующей записи на false.

Для иллюстрации этой концепции рассмотрим сценарий, в котором у нас есть таблица с названием “ValveImport” с колонками, такими как ValveOutput, ValveInput, MeasurementTime, ValveId и ImportFlag. Мы можем создать таблицу мягкой транзакции, скопировав существующую таблицу и добавив новую колонку с названием “True” со значением по умолчанию 1. Этот столбец представляет истинное значение записи.

-- Создание новой таблицы с первичным ключом из существующей таблицы:
SELECT *
INTO newValveImport
FROM ValveImport

-- Добавление новой колонки
ALTER TABLE newValveImport ADD True BIT DEFAULT (1) NOT NULL

SELECT *
FROM newValveImport

Теперь, когда у нас есть таблица мягкой транзакции, мы можем выполнять транзакции с ее использованием. Вместо использования команды DELETE мы обновляем флаговый столбец, чтобы пометить запись как неактивную. Для операции вставки мы проверяем, существует ли запись с тем же первичным ключом. Если она существует, мы обновляем существующую запись на false, а затем вставляем новую запись. Это гарантирует, что одна запись с истинным значением существует в любой момент времени.

-- Мягкая транзакция обновления
DECLARE @valveid VARCHAR(12) = 'newrecord111'

BEGIN TRAN

IF EXISTS (SELECT ValveId FROM newValveImport WHERE ValveId = @valveid AND True = 1)
BEGIN
    UPDATE newValveImport
    SET True = 0
    WHERE ValveId = @valveid
END

INSERT INTO newValveImport (ValveId, ValveOutput, ValveInput, MeasurementTime, ImportFlag) 
VALUES (@valveid, @output, @input, GETDATE(), 0)

COMMIT TRAN

SELECT *
FROM newValveImport
WHERE ValveId = 'newrecord111'

Соображения при использовании мягких транзакций

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

Размер данных и производительность

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

Рост данных и обслуживание

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

Резервное копирование и избыточность

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

Откат данных и архивирование

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

Доступ разработчика и оптимизация производительности

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

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