Атомарность связывает результат нескольких изменений. Согласованность требует, чтобы этот результат соблюдал заданные правила. Две неверные суммы можно записать вместе и надёжно; для правильного заказа нужны проверяемые ограничения и корректная логика.
Практический смысл
Почему это важно
Остаток не должен стать отрицательным, номер заказа — повториться, а скидка — превысить согласованный предел. Для каждого правила нужен конкретный исполнитель проверки. Надёжная фиксация неверной суммы делает ошибку устойчивой, но не превращает её в допустимую продажу.
Доказательная часть
Что подтверждено
Согласованная транзакция сохраняет заданные правила допустимого состояния, если начинает работу из допустимого состояния. Правила и корректная логика изменения должны быть определены заранее: слово ACID не описывает, какой заказ коммерчески верен.
Граница применимости: Свойство C в классической модели транзакций; правила допустимого состояния также называют инвариантами.
Согласованность ACID относится к правилам данных. Атомарная согласованность в формализации CAP и линеаризуемость относятся к наблюдаемому порядку операций. Сохранение правильной суммы заказа не устанавливает, когда её увидит чтение через другую реплику.
Граница применимости: Сопоставление моделей ACID, CAP и линеаризуемости; пример реплики не задаёт конкретного протокола репликации.
В PostgreSQL 18 ограничения задают конкретные проверки данных: NOT NULL запрещает отсутствие значения, CHECK проверяет логическое условие строки, UNIQUE запрещает дубли в объявленном наборе столбцов с учётом выбранной обработки NULL. Эти механизмы защищают выраженные правила, а не произвольный смысл заказа.
Граница применимости: PostgreSQL 18, ограничения таблиц. CHECK не является общей проверкой изменяемых данных в других строках или таблицах.
В PostgreSQL 18 CHECK считается выполненным, если его выражение истинно либо даёт NULL. Поэтому проверка положительной суммы сама по себе не запрещает отсутствующую сумму: если значение обязательно, требуется также NOT NULL или иное явно достаточное ограничение.
Граница применимости: PostgreSQL 18, CHECK и трёхзначная логика SQL; пример числовой суммы с обычным сравнением на положительность.
Атомарная и долговечная запись может сохранить неверную скидку или перевод не тому получателю, если это правило не выражено в ограничениях и корректной логике. Успешная фиксация означает принятие результата базой, а не независимую проверку делового замысла.
Граница применимости: Редакторский вывод о границах технических свойств и заданных ограничений; согласованность по невыраженному деловому правилу не доказана.
Проверка «такого номера заказа ещё нет» отдельным чтением не равна ограничению уникальности. На PostgreSQL 18 Read Committed две транзакции могут обе не увидеть чужую незавершённую вставку; для обязательной уникальности конкретного номера нужна её защита при записи, например UNIQUE вместе с NOT NULL.
Граница применимости: Редакторский пример PostgreSQL 18 для одного обязательного номера заказа; не готовый протокол дедупликации внешних платежей.
Граница терминов
Не путать
Согласованность ACID оценивает допустимость данных после транзакции. Условие согласованности в CAP оценивает допустимый порядок операций при сетевой модели. Назвать оба свойства одним словом недостаточно для выбора пути чтения или проверки заказа.
Перед спецификацией
Что проверить
- Запишите правила заказа проверяемо: обязательная сумма, допустимая скидка, неотрицательный остаток и уникальный номер.
- Для каждого правила укажите ограничение базы или точную операцию приложения, которая его обеспечивает.
- Проверьте не только неверные числа, но и NULL, пустые значения и граничные суммы.
- Убедитесь, что CHECK не используется как обещание автоматически перепроверять меняющиеся данные другой строки.
- Одновременно создайте два заказа с одним номером и проверьте, где именно второй запрос отклоняется.
- Проверьте откат всего заказа при нарушении ограничения, включая уже выполненное изменение остатка.
- Добавьте в приёмку пример формально допустимой, но коммерчески неверной скидки и установите владельца этого правила.
Открытые основания
Первоисточники
The Transaction Model — Turing Award Lecture
Microsoft Research / ACM · Jim Gray, FCRC 1999 lecture slides
Первичный обзор transaction model, ACID, concurrency anomalies, logs и two-phase commit.
Открыть первоисточникBrewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services
MIT Laboratory for Computer Science · Gilbert and Lynch, SIGACT News 33(2), 2002
Формализует CAP impossibility для atomic consistency и availability в asynchronous network model.
Открыть первоисточникLinearizability: A Correctness Condition for Concurrent Objects
Carnegie Mellon University / ACM · Herlihy and Wing, ACM TOPLAS 12(3), July 1990
Даёт формальное real-time correctness condition для concurrent operations.
Открыть первоисточникPostgreSQL 18 Documentation: Constraints
PostgreSQL Global Development Group · документация PostgreSQL 18, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Проверить CHECK и NULL, NOT NULL, UNIQUE и границу проверок одной строки; пример заказа — редакторское применение этих правил.
Открыть первоисточникPostgreSQL 18 Documentation: Transaction Isolation
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 13.2
Определяет isolation phenomena и фактическое поведение PostgreSQL levels, включая Serializable.
Открыть первоисточник