databasedatabase-designconsistencyatomic

Can a database support "Atomicity" but not "Consistency" or vice-versa?


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!


Solution

  • 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 is that either both rows or neither will be added.

    On the consistency front, let's say you have a foreign key constraint from orders to products. 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.