在他的“数据库系统简介”一书中，CJDate 写了一个关于 ACID 原则的章节，称为“Dropping ACID”。在本章中，他称正确性（一致性）“本质上毫无意义”，而其他原则至多是“一种迫切需要”。
这本书是 2004 年出版的，我在互联网上的任何地方都将 ACID 原则视为 RDBMS 应用程序编程的指南。这是否意味着 Date 对 ACID 的想法没有被接受？或者从理论的角度来看，ACID 是否不像在阅读有关数据库编程的 Internet 文档时看起来那样强制性？
我希望我的问题有意义并且在正确的论坛中。
书的内容
作者从非常理论的角度分析了ACID的概念。
最重要的部分可能是本章最后一段的第一句话：
另一个重要部分是他引入了“多重赋值”运算符（第 487 页），他将其用作解决实际 DBMS 通过支持事务处理的一些问题。此操作在MySQL、Oracle或MSSQL中似乎不起作用。（使一次查询更新多个表成为可能。）
他的陈述是：如果我们有这个多重赋值运算符，则不需要延迟检查约束并且应该立即应用而不是在事务结束时应用。后一个导致 ACID 的C变得无用，因为数据库总是一致的（如果 C 代表一致性）或者它的正确性是不可执行的（如果 C 代表正确性）。
关于隔离，他声称这应该意味着所有事务都应该完全不知道其他事务可能正在运行。这可能是行不通的。他进一步指出，大多数 DBMS 都提供“隔离级别”设置，这从根本上破坏了这个概念。
如果支持嵌套事务，他写的持久性只能应用于最外层的事务。
根据他的说法，只有当需要交易时才需要原子性。如果多重赋值运算符可用作原子，则不需要原子事务。
带走什么
这是关于 ACID 概念的非常基础的讨论。在不判断他的批评是否正确的情况下，有一个基于事务的 DBMS 的活生生的景观。
CJ Date 自己写道，“我们现在对这项研究所依据的一些假设有了更好的理解”。这意味着它是基本方面之一，在实时 DBMS 中无法轻易更改。删除事务并推入原子多重赋值运算符，没有企业会想要更新其架构，因为这是很多变化。
因此，您已经阅读了一个理论章节，该章节宣告了如何从概念上改进 DBMS 的属性，并且从根本上消除了一些问题。但只是因为有些东西可能更胜一筹，所以不会马上付诸实践。
你基本上已经达到了纯粹理论观点的人与实际世界之间的边界，其中不仅仅是理论，而是一个必须环绕的现有世界。
ACID的一致性部分与事务之前、期间和之后的数据状态有关。
当涉及到引用完整性时，外键应该正确连接，没有丢失任何键。这意味着围绕级联规则、触发器和约束的每个操作都必须是全有或全无（从头到尾，或者一路倒退，这样信息前后看起来都一样）。在许多情况下，一致性可能超出 RDBMS 的范围并在应用程序级别强制执行。为什么？
业务逻辑可能会变得越来越复杂，并且需要应用程序编码来消除 RDBMS 的一致性，尤其是在存储过程不够强大且业务逻辑可以由客户端完成的情况下。
可以说 ACID 的一致性完全适用于 RDBMS 内部的所有操作（级联规则、触发器、约束、存储在 DBMS 中的 BI）。除此之外，任何 BI 的使用都会使 ACID 的一致性变得毫无意义。毕竟，一旦在应用程序级别处理了数据的一致性，您就可以像使用 MySQL 和 SQLite 一样使用 Oracle 和 SQL Server 处理数据。
数据库设计和应用程序设计需要进行大量的深思熟虑。因此，你可以说
如需进一步的观点，请参阅我的旧帖子What are the arguments against or for putting application logic in the database layer？（以及提供的其他答案）看看 DBA 和开发人员有哪些定义一致性的纠缠以及我的另一篇旧文章你应该在编写应用程序代码之前设计数据库吗？（以及提供的其他答案）。
我想关键是在现实生活中，由于工程限制和应用程序功能和非功能要求，SQL 数据库无法在其理论范围内完全实现该原则。想想“脏读”、嵌套事务、延迟约束、进程和线程同步限制等。