The official definition of the set of properties governing database transactions is mentioned as Atomic, Consistent, Isolated, and Durable (known as ACID). These are the four tenants of a database transaction. Broken down, they mean the following:
- Atomic: All work that must be performed by the database inside a transaction – that is, reading data, deleting data, updating data, and/or inserting data – is treated as a single unit of work. It's literally all-or-nothing. If anything fails, then it all fails, and you revert back to the way the universe was before you'd gone and mucked it all up.
- Consistent – This is basically The Principle of Least Astonishment; that is, there are no surprises, and everything is as you expect it to be. Foreign keys and other constraints are respected, the state of the data prior to the transaction is used within the transaction, etc. In short a transaction should never, ever leave you with the thought, Huh, how did that happen?!
- Isolated: It determines just how much of your transaction you want other users of the database to see, and when. For example, perhaps you still want to give others read access to the data while you manipulate it, or maybe you want exclusive access to it until you're done. There's a trade-off for each. Basically, isolation is to database transactions what window curtains are to you when walking around your apartment naked.
- Durable: This means that when the transaction is complete and committed, the state of that data is there to stay. It's permanent. Even if you've screwed it up. So don't screw it up.
Ultimately, ACID can be boiled down to a very simple concept: Guaranteed to work, or nothing at all.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.