Dimitry Sibiryakov
artemana
Но и архи сложного вроде ничего нет. Внутри транзакции небольшой журнальчик, содержащий
сведения только о тех записях, которые размещены транзакцией в ‘невалидном’ состоянии.

Так-то оно так, но беда в том, что и валидная запись может стать инвалидной к концу
транзакции. Т.е. надо хранить журнал всех изменённых записей, а он уже на "небольшой" не
тянет.

Что ты имеешь виду?

Dimitry Sibiryakov
artemanaЧто ты имеешь виду?

Берём, например, FK. Добавляем запись к существующему мастеру - операция валидна. Удаляем
мастера - операция инвалидна. Вставляем нового мастера с тем же PK - операция валидна.
Коммитим. Получаем облом на удаление мастера, поскольку деталь для него существует. А зря.

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

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

Dimitry Sibiryakov
artemana
Запись в таком журнале идентифицируется по типу ограничения, PK-невалидной записи и
идентификатору ее таблице.

В морг. Целые числа в качестве РК обычное явление, но отнюдь не требование. Плюс не надо
забывать unique constraints, check constraints и т.д. и т.п.

Раз есть FK, значит есть PK, храни его в журнале. Причем здесь целые числа, из каких глубин своего подсознания ты их достал, ведь я о них не упоминал?

Причем здесь морг, я к тебе с просьбой о мед помощи о реализации вроде не обращался?
Dimitry Sibiryakov
Плюс не надо
забывать unique constraints, check constraints и т.д. и т.п.

Ну и ?

Dimitry Sibiryakov
Ты упомянул РК невалидной записи. Значение РК может достигать в размере четырёх килобайт.
Журнал при таких условиях в память может и не влезть.


А почему он (журнал) должен быть только в памяти??? Пусть, как и обычные таблицы, располагается на страницах БД, которые если журнал небольшой, за счет частого обращения, будут в кеше, или если он большой, будут вытесняться на диск. При большом количестве больших "инвалидов" падение производительности вполне допустимо. И кстати, оно не будет больше, чем при проверке уникальности PK или другого уникального ограничение на поле.