数据库可以支持“原子性”吗？但不是“一致性”或者反之亦然？
我正在阅读有关数据库的 ACID 属性的内容。原子性和一致性似乎密切相关。我想知道是否有任何场景我们需要只支持原子性而不支持一致性，反之亦然。一个例子真的很有帮助！
I am reading about ACID properties of a database. Atomicity and Consistency seem to be very closely related. I am wondering if there are any scenarios where we need to just support Atomicity but not Consistency or vice-versa. An example would really help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
它们有一些相关性，但也有细微的差别。
原子性意味着你的交易要么发生，要么不发生。
一致性意味着诸如引用完整性之类的事情得到强制执行。
假设您启动一个事务来添加两行（构成单个银行事务的贷方和借方）。这个的原子性与数据库的一致性无关。这意味着要么添加两行，要么不添加任何行。
在一致性方面，假设您有一个从
orders到products的外键约束。如果您尝试添加引用不存在产品的订单，那么一致性就会开始阻止您执行此操作。两者都是为了将数据库维护在可用状态，因此它们很相似。前一个示例将确保银行不会赔钱（或从您那里偷钱），后者将确保您的应用程序不会对您一无所知的产品订单感到惊讶。
They are somewhat related but there's a subtle difference.
Atomicity means that your transaction either happens or doesn't happen.
Consistency means that things like referential integrity are enforced.
Let's say you start a transaction to add two rows (a credit and debit which forms a single bank transaction). The atomicity of this has nothing to do with the consistency of the database. All it means it that either both rows or neither row will be added.
On the consistency front, let's say you have a foreign key constraint from
orderstoproducts. If you try to add an order that refers to a non-existent product, that's when consistency kicks in to prevent you from doing it.Both are about maintaining the database in a workable state, hence their similarity. The former example will ensure the bank doesn't lose money (or steal it from you), the latter will ensure your application doesn't get surprised by orders for products you know nothing about.
原子性：
一致性：
支持原子性但不支持一致性的数据库将允许事务使数据库处于不一致状态（即，违反引用或其他完整性检查），前提是事务成功完成。例如，您可以将字符串添加到 int 列，前提是执行此操作的事务成功完成。
相反，支持一致性但不支持原子性的数据库将允许部分事务完成，只要该事务的影响不会破坏任何完整性检查（例如，外键必须与现有身份匹配）。
例如，您可以尝试添加包含 string 和 int 值的新行，即使插入中途失败，丢失一半数据，只要丢失的数据都不是所需列且没有数据，则将允许该行被插入到输入错误的列中。
话虽如此，一致性依赖于逆转不一致事务的原子性。
Atomicity:
Consistency:
A database that supports atomicity but not consistency would allow transactions that leave the database in an inconsistent state (that is, violate referential or other integrity checks), provided the transaction completes successfully. For instance, you could add a string to an int column provided that the transaction performing this completed successfully.
Conversely, a database that supports consistency but not atomicity would allow partial transactions to complete, so long as the effects of that transaction didn't break any integrity checks (e.g. foreign keys must match an existing identity).
For instance, you could try adding a new row that included string and int values, and even if the insertion failed half way through losing half the data, the row would be allowed provided that none of the lost data was for required columns and no data was inserted into an incorrectly typed column.
Having said that, consistency relies on atomicity for the reversal of inconsistent transactions.
原子性和一致性之间确实存在很强的关系，但它们并不相同：
DBMS 可以（理论上）支持一致性而不是原子性：例如，考虑一个由 SQL 操作 O1、O2 和 O3 组成的事务。现在，假设在 O1 和 O2 之后 DB 已经处于一致状态。然后，DBMS 可以在 O1 和 O2 之后停止事务，而无需 O3，并且仍然保持一致性。显然，这样的 DBMS 不支持原子性（因为 O3 不是由 O1 执行，而 O2 是）。
DBMS 可以（理论上）支持原子性而不是一致性：这可能发生在多用户场景中，其中原子性仅确保事务的所有操作都将被执行（或不执行任何操作），但它不能保证一个事务与另一事务同时执行的操作可能不会以不一致的状态结束。
然而，我确实相信（但尚未正式证明）的是，如果您的 DMBS 保证原子性和隔离性，那么它也必须保证一致性。
There is indeed a strong relation between Atomicity and Consistency, but they are not the same:
A DBMS can (theoretically) support Consistency and not Atomicity: for example, consider a transaction that consists SQL operations O1,O2, and O3. Now, assume that after O1 and O2 the DB is already in a consistent state. Then the DBMS can stop the transaction after O1 and O2 without O3 and still preserves consistency. Clearly, such a DBMS does nto supports atomicity (as O3 was not executed by O1 and O2 was).
A DBMS can (theoretically) support Atomicity and not Consistency: this can occur in a multi-user scenario, where atomicity only ensures that all actions of a transaction will be performed (or none of them) but it does not guaranteee that actions of one transaction done concurrently with another transaction may not end up in an inconsistent state.
However, what I do believe (but have not proven formally) is that if your DMBS guarantees both Atomicity and Isolation, then it must also guarantee Consistency.
在阅读有关原子性和原子性的内容时，我也感到困惑。一致性。假设有一个场景要在帐户表中批量插入 1000 条记录。
批次的原子性是指1000条记录全部插入，或者出现错误则不插入任何记录。
如果在帐户记录级别，我们放置了即使数据类型不匹配也能成功插入的逻辑，并且相关记录已插入到外键表中，并且将违反批次的一致性帐户记录更新成功后删除。
希望这个例子能消除困惑。
I was also getting confused when reading about atomicity & consistency. Let's say there is scenario to do batch insert of 1000 records in the account table.
Atomicity of the batch is if all the 1000 records are inserted or none of the records are inserted if there is an error.
Consistency of the batch will be violated if at the account record level, we have put the logic to make the insert successful even if data type didn't match, related record was inserted in the foreign key table and later deleted after the successful account record update.
Hopefully this example clears the confusion.
我对 ACID 上下文中的一致性有不同的理解：
在事务中，如果检索给定的数据项并稍后在同一事务中再次检索，则不会看到任何更改。也就是说，在整个事务过程中，事务被赋予数据库的一致状态。唯一可以更改事务可见数据的更新是事务本身完成的更新。
在我看来，这相当于可串行化。
I have a different understanding of consistency in the ACID context:
Within a transaction, if a given item of data is retrieved and retrieved again later in the same transaction, no changes are seen. That is, the transaction is given a consistent state of the database throughout the transaction. The only updates that can change data visible to the transaction are updates done by the transaction itself.
In my mind, this is tantamount to serializability.