ACID properties are very useful in relational database. It gives you confidence that your data will always be consistent no matter how many transactions will occur at a time or in case of system failure.
ACID stands on
A: Atomic
C: Consistent
I: Isolate
D: Durable
Let’s see each property in detail.
Atomic
“All or none” – It means a transaction can have multiple tasks to execute so all these tasks in a transaction should be committed to database or none should be committed. If it won’t be happened then data will remain in inconsistent state. See below example how data will remain in inconsistent state if database not follow atomicity property.
Person A’s balance: 1000 INR
Person B’s balance: 1500 INR
Person A needs to transfer 100 INR to B’s account.
So to perform one transaction, two tasks will be executed (debit of INR from one account and credit it to another one) So after successful transaction, balance in both accounts should be
Person A’s balance: 900 INR
Person B’s balance: 1600 INR
But what happened if INR will be debited from A’s account and not credited to B’s account due to any reason like system failure?
Person A’s balance: 900 INR
Person B’s balance: 1500 INR
So here, the database is in inconsistent state. But, if we follow Atomicity property then it should rolled back this transaction.
Consistent
Consistency means integrity constraint must be maintained so database will remain in consistent state before and after the execution of transaction. So again if we see above example, then it’s tell you that at the end, your database must be in consistent state.
Isolate
It is possible that at a time, more than one transactions may occur. So in that case, each transaction should run separately from every other transaction and database should remain in consistent state. Let’s see below example.
Example
In above example, money debited from person A’s account but before credited to B’s account, some other transaction (called transaction T2) will debit some amount from person A’s account. In that case, total balance of Person A’s account will not be correct after transaction T2’s execution. So it’s always ideal that every transaction must be separated/isolated from other every transactions.
Durable
When a transaction is running, power failure or any other network related issue may occur. So if transaction has been committed then all changes must be reflected in database and all changes must be written on disk. None of the changes should be lost.
Nice!