数据库是否可以支持“原子性”但不支持“一致性”，反之亦然？

Question

我正在阅读有关数据库的ACID属性的信息。原子性和一致性似乎非常密切相关。我想知道是否有任何情况我们需要支持Atomicity但不支持Consistency，反之亦然。一个例子真的有帮助！

Answer 1

他们 有点相关，但有一个微妙的区别。

原子性意味着您的交易发生或不发生。

一致性意味着强制执行参照完整性等事项。

假设您开始交易以添加两行（信用卡和借记卡，形成单个银行交易）。这种原子性与数据库的一致性无关。这意味着它将同时添加两行或两行。

在一致性方面，假设您有orders到products的外键约束。如果您尝试添加一个引用不存在产品的订单，那么当一致性启动时就是，以防止您这样做。

两者都是关于将数据库维持在可行状态，因此它们的相似性。前一个例子将确保银行不会赔钱（或从您手中窃取），后者将确保您的申请不会对您不了解的产品订单感到惊讶。

Answer 2

原子性：

  

在原子交易中，一系列   数据库操作全部发生，   或什么也没发生。保证   原子性阻止更新   数据库仅部分发生，   这可能会导致更大的问题   完全拒绝整个系列。

一致性：

  

在数据库系统中，一致   交易是没有的   违反任何完整性约束   在执行期间。如果是交易   使数据库处于非法状态   状态，它被中止，错误是   报告

如果事务成功完成，则支持原子性但不具有一致性的数据库将允许使数据库处于不一致状态（即违反参照或其他完整性检查）的事务。例如，您可以将字符串添加到int列，前提是执行此操作的事务已成功完成。

相反，支持一致性而非原子性的数据库将允许部分事务完成，只要该事务的效果不会破坏任何完整性检查（例如，外键必须与现有标识匹配）。 例如，您可以尝试添加一个包含字符串和int值的新行，即使插入失败了一半数据，也可以允许该行，前提是没有丢失的数据用于所需的列且没有数据被插入到错误输入的列中。

话虽如此，一致性依赖于原子性来逆转不一致的交易。

Answer 3

我对ACID背景下的一致性有不同的理解：

在事务中，如果稍后在同一事务中检索并检索给定的数据项，则不会看到任何更改。也就是说，在整个事务中，事务被赋予数据库的一致状态。可以更改事务可见数据的唯一更新是事务本身完成的更新。

在我看来，这相当于可串行化。

Answer 4

在阅读有关原子性的信息时，我也感到困惑。一致性。假设有一种情况可以在帐户表中批量插入1000条记录。

如果插入了所有1000条记录，或者如果出现错误，则不会插入任何记录，

原子性。

如果在帐户记录级别，即使数据类型不匹配，我们也会使逻辑插入成功，相关记录被插入到国外，将违反批次的一致性密钥表，稍后在成功更改帐户记录后删除。

希望这个例子能够解决这个问题。

Answer 5

原子性与一致性确实存在很强的关系，但它们并不相同：

1. DBMS可以（理论上）支持一致性而不是原子性：例如，考虑一个包含SQL操作O1，O2和O3的事务。现在，假设在O1和O2之后，DB已经处于一致状态。然后DBMS可以在没有O3的情况下在O1和O2之后停止事务，并且仍然保持一致性。显然，这样的DBMS不支持原子性（因为O3不是由O1和O2执行的）。

2. DBMS可以（理论上）支持原子性而不是一致性：这可以在多用户场景中发生，其中原子性仅确保将执行事务的所有操作（或者不执行任何操作）但它确实执行不保证一个事务与另一个事务同时执行的操作可能不会以不一致的状态结束。

但是，我确实相信（但尚未正式证明）如果您的DMBS同时保证原子性和隔离性，那么它也必须保证一致性。