Вердикт такой:
СУБД либо ведет журнал транзакций, либо не отвечает требованиям ACID.
Причём здесь требования ACID? Мы говорили:
Это Вам придётся учитывать (я с MS SQL не работаю), на Firebird, к примеру, никакого журнала транзакций нет.
Неужели? А как он транзакции выполняет?
То есть, с Вашей точки зрения без журнала транзакций выполнить транзакцию невозможно. На это я и возражал. Теперь Вы переводите разговор на ACID... Не спортивно.
Теперь в двух словах я Вам расскажу о том, как работают блокировочные и версионные СУБД, и почему для работы (не для восстановления!) версионным СУБД не нужен журнал транзакций.
Блокировочная СУБД меняет данные по месту их хранения, затирая старые данные новыми значениями. Но
в момент изменения данных никто не знает того, как завершится транзакция (да, и завершится ли она вообще). Поэтому, на случай отката (rollback) или сбоя, старые данные из записи переносятся в журнал транзакций. К новым данным другие (читающие и пишущие) транзакции доступа не имеют (поскольку эти данные ещё могут "откатить"). Доступ к новым/обновлённым данным открывают только после фиксации (commit) транзакции. Это создаёт большое количество проблем...
Версионная СУБД для меняемых данных создаёт новую версию (в случае добавления записи новая запись первоначально пуста; при изменении старой записи, она копируется в новую область), и в этой новой области происходит редактирование записи. Старая запись не меняется никогда! Поэтому переносить её в журнал для возможного отката нет никакой необходимости, а значит и нет никакого журнала транзакций (для целей отката). Каждая запись имеет маркер той транзакции, которая её создала/изменила. Если меняющая транзакция завершается фиксацией, то актуальна новая запись, если завершается откатом, то актуальной остаётся старая запись. Старая запись не удаляется даже после того, как изменившая её транзакция была зафиксирована, поскольку могут быть транзакции, которые в ней заинтересованы (это те транзакции, которые стартовали раньше, чем меняющая транзакция и имеющие высокие уровни изолированности repeatable read и выше (хотя у версионных СУБД иные уровни изолированности, отличные от блокировочных)). Удаление старых записей возможно только тогда, когда не существует заинтересованных в них транзакций. Такая (версионная) форма изоляции транзакций позволяет пишущей/меняющей транзакции не блокировать данные от читающих транзакций. В существующих версионных СУБД, куда теперь относится и MS SQL пишущие/меняющие одну и ту же запись транзакции блокируются. Но возможен вариант полноверсионной СУБД, когда даже пишущие одну и ту же запись транзакции не блокируют друг друга. Это открывает интересные возможности, прежде всего... в системах принятия решений... Но это уже совсем другая тема.
Что же касается ACID (речь про D - durability), то надо либо поддерживать журнал, либо сохранять БД после каждого COMMIT пишущих транзакций. Firebird не имеет журнала транзакций и поэтому эта СУБД не в полной мере соответствует требованиям ACID. С другой стороны, поддержка журнала для версионных СУБД не такое трудное дело (в отличие от блокировочных), и почему команда Firebird до сих пор этого не сделала, для меня остаётся загадкой.
