When Kittens and ACID Get Along
I learned how to spell bologna thanks to Oscar Myer’s theme song back in the day. When Gwen Stefani came out with Hollaback Girl, I was forever doomed to sing the correct spelling of bananas every time I wrote it on my grocery list (has anyone done this for broccoli yet?) Now if only they could translate the ACID model into a theme song, we’d all be set when working with databases.
The ACID model is what everyone should aim for when working in a database. Since data is so important (just ask Google and Facebook, forever wanting all the data), it’s even more important that the database in which it’s stored is reliable, which ensures the database transaction is processed reliably. If your database might not be reliable, what’s the point of gathering and storing all that data in the first place?
To follow the ACID model, your database must have these four characteristics:
Atomicity: Your database must follow the “all or nothing” rule. If one family who is trying to adopt a kitten is able to complete all parts of the adoption procedure except one, then they can’t take the kitten home. It doesn’t matter what the circumstance is or what part of the procedure they couldn’t pass, no kitten for them! This leaves the family very distraught and sad, because they knew they passed all parts of the adoption procedure. There must have been a mistake. Without the procedure being Atomic, or having the Atomicity characteristic, any failure in any part of the system under any circumstance makes the whole database unreliable. It’s kind of a big deal.
Consistency: Make sure only valid data is being written in the database. This sounds like a no brainer, but there’s always something that could happen. The family decides they want to adopt two kittens instead of one (yay!) but the transaction for the first kitten is halfway complete and the second kitten can’t be added on. For consistency’s sake, each transaction must include all animals that were adopted and fees paid at the same time. Instead of pushing the first transaction and starting a new one for the second kitten, the first transaction should be rolled back and a completely new one started for both kittens. If you’re not careful, you could end up with two transactions for the same kitten, or end up missing a kitten altogether. #nokittenleftbehind
Isolation: Transactions should not interfere with one another while they’re running at the same time. Let’s say Hannah is adopting a kitten named Mary Kate. She is entering all her information into the required form so the database can keep track of the transaction. At the same time, Liam is adopting a kitten named Ashley and is also filling out the form. By some crazy coincidence, they both hit the submit button at the same time. If the database has the Isolation characteristic down, it will process and complete either Hannah’s OR Liam’s transaction before moving on to the next transaction. This ensures that when the adoption papers are printed, Hannah won’t get hers with the name Ashley on them and Liam won’t get Mary Kate. I’m sure the kittens will appreciate not getting their names mixed up.
Durability: Any transaction that is being committed to the database won’t be lost. It’s one thing to make sure every transaction is being submitted correctly, and another to store them and make sure it’s never lost no matter what hardware or software failures could happen. Every single kitten from the time our hypothetical shelter opened its doors will be documented, and their adoption records kept for the shelter to forever be happy about.
Keeping a healthy and reliable database is imperative to any successful venture, from finding kittens homes to getting a great idea for an app off the ground. Just remember ACID, and forever bask in the reliability of your beautiful database.