История изменений

C в ACID — это consistency.

Да, но консистентность определяется выполнением констрейнтов, а не как-то абстрактно

Слушай, а мне кажется, что ты прав. Ну то есть есть разные интерпретации, но вообще-то они появились потому, что всякие Oracle, MS SQL, MySQL, PostgreSQL и прочие чаще предпочитают не поддерживать Consistency, чем поддерживать ее. А вместо этого за «consistency» выдают «согласованность тухлых данных снимка».

Это история вроде криков про поддержку ANSI SQL в Oracle RDBMS, хотя по факту 2 из 4 режимов изоляции стандарта оно не поддерживает в принципе вообще никак (dirty read и read committed).

Элементарно две транзакции добавили две недопустимо похожих записи

Приведи пример

CREATE TABLE Persons (
    PersonID int
);

Обе транзакции выполняют:

INSERT INTO Persons (PersonID) 
SELECT 1
FROM dual
WHERE NOT EXISTS(SELECT * 
                 FROM Persons  
                 WHERE (PersonID = 1));

При одновременном их выполнении в таблице оказывается две записи с PersonID = 1, поскольку в начале обоих транзакций select * from Persons where (PersonID = 1) был пустым множеством.

Правда, это не Write Skew, это просто несериализуемые транзакции — результат их одновременного выполнения отличается от последовательного выполнения. «Select for update» по всем прочитанным записям полностью устраняет феномен Write Skew и потому соответствует уровню Repeatable Reads из ANSI SQL, которое ниже уровня Serializable.

C в ACID — это consistency.

Да, но консистентность определяется выполнением констрейнтов, а не как-то абстрактно

Слушай, а мне кажется, что ты прав. Ну то есть есть разные интерпретации, но вообще-то они появились потому, что всякие Oracle, MS SQL, MySQL, PostgreSQL и прочие чаще предпочитают не поддерживать Consistency, чем поддерживать ее. А вместо этого за «consistency» выдают «согласованность тухлых данных снимка».

Это история вроде криков про поддержку ANSI SQL в Oracle RDBMS, хотя по факту 2 из 4 режимов изоляции стандарта оно не поддерживает в принципе вообще никак (dirty read и read committed).

Элементарно две транзакции добавили две недопустимо похожих записи

Приведи пример

CREATE TABLE Persons (
    PersonID int
);

Одна транзакция:

insert into Persons (PersonID) 
select 1
from dual
where not exists(select * 
                 from Persons  
                 where (PersonID = 1));

Вторая транзакция та же самая. При одновременном их выполнении в таблице оказывается две записи с PersonID = 1, поскольку в начале обоих транзакций select * from Persons where (PersonID = 1) был пустым множеством.

Правда, это не Write Skew, это просто несериализуемые транзакции — результат их одновременного выполнения отличается от последовательного выполнения. «Select for update» по всем прочитанным записям полностью устраняет феномен Write Skew и потому соответствует уровню Repeatable Reads из ANSI SQL, которое ниже уровня Serializable.