The Quest of ACID

The Quest of ACID

MySQL and NoSQL

Understanding the ACID Principles: Database Design Basics | by Patrick  Karsh | Cracking The Coding Interview in Ruby, Python And JavaScript | Sep,  2023 | Medium

Hello, fellow coders and database enthusiasts! Have you ever had a moment in your coding journey where your data behaved like a rebellious teenager — unpredictable and refusing to follow the rules? Well, fear not, because I'm here to introduce you to the parental figures of database management: the ACID principles. These are not your average science lab acids, but they sure can prevent your database from corroding!

What Does ACID Stand For?

ACID is like the superhero team of databases, where each letter stands for a superpower:

  • A for Atomicity: Think of it as the all-or-nothing approach. Just like how you can't be 'kind of' skydiving (you're either in the plane or hurtling towards Earth), a transaction in your database must be all in or not at all.

  • C for Consistency: This ensures your database doesn't wake up one day deciding to be a spreadsheet. Consistency keeps your data in line with predefined rules. It's like having a stern librarian who makes sure every book is in its right place.

  • I for Isolation: This one's the introvert of the group. It ensures that transactions run as if they are the only ones in the database, avoiding those awkward interactions where one transaction bumps into another.

  • D for Durability: Like a superhero's promise, once a transaction is committed, it's set in stone. Even if the power goes out or your server decides to take a nap, you won’t lose your precious data.

Chapter 1: Atomicity - The "All or Nothing" Stage Play

MySQL's Drama:

Scenario: Imagine you're running an online bookstore. A customer orders a book and a bookmark.

MySQL Code:

START TRANSACTION;
INSERT INTO orders (product, customer_id) VALUES ('The Hitchhiker’s Guide to the Galaxy', 42);
INSERT INTO orders (product, customer_id) VALUES ('Galaxy Bookmark', 42);
COMMIT;

Here, either both items are ordered, or none. It's like ordering a burger and fries; you don't just want the burger!

NoSQL's Twist:

Scenario: Same bookstore, but in a NoSQL world (let's say, MongoDB).

NoSQL Code:

db.orders.insertOne(
    { order_id: "1234", products: ['Hitchhiker’s Guide', 'Galaxy Bookmark'], customer_id: 42 }
);

In MongoDB, the whole order is a single document. Atomicity is at the document level, ensuring the entire order is processed or none of it.

Chapter 2: Consistency - The "Keeping It Real" Episode

MySQL's Reality Check:

Scenario: A user tries to input their age as 'Thirty-Five' in an integer field.

MySQL Code:

CREATE TABLE users (id INT, age INT);
INSERT INTO users (id, age) VALUES (1, 'Thirty-Five'); -- This will cause an error

MySQL ensures your data types are as consistent as your dislike for Mondays.

NoSQL's Flexibility Show:

Scenario: In a NoSQL database, you're storing varied user data.

NoSQL Code:

db.users.insertOne({ name: "Alice", age: "Thirty-Five", interests: ["Chess", "AI"] });

NoSQL is more flexible with data types, but it’s on you to maintain consistency, like ensuring you wear pants for a Zoom call (at least the visible part).

Chapter 3: Isolation - The "Parallel Universe" Saga

MySQL's Parallel Timelines:

Scenario: Two users simultaneously updating their profiles.

MySQL Code:

-- User 1:
START TRANSACTION;
UPDATE users SET bio = 'Love cats' WHERE id = 1;

-- User 2:
START TRANSACTION;
UPDATE users SET bio = 'Love dogs' WHERE id = 2;
COMMIT;

COMMIT; -- User 1

MySQL's isolation ensures User 1’s love for cats doesn't get mixed up with User 2’s dog preference.

NoSQL's Relaxed Reality:

Scenario: Same situation, but in the NoSQL universe.

NoSQL Code:

// User 1
db.users.updateOne({ id: 1 }, { $set: { bio: "Love cats" } });

// User 2
db.users.updateOne({ id: 2 }, { $set: { bio: "Love dogs" } });

NoSQL handles isolation more casually, but you may need additional logic to prevent cosmic crossovers.

Chapter 4: Durability - The "Written in Stone" Documentary

MySQL's Permanent Record:

Scenario: After a transaction, the server crashes.

MySQL Code:

START TRANSACTION;
INSERT INTO logs (message) VALUES ('Server is about to crash!');
COMMIT;

Even after a crash, this log remains in MySQL, like a prophecy etched in stone.

NoSQL's Cloud Chronicle:

Scenario: You’ve logged data, and then there’s a system failure.

NoSQL Code:

db.logs.insertOne({ message: "Oops, system hiccup!" });

In NoSQL, data durability is often ensured through replication and backups, akin to making multiple copies of your secret diary.

Epilogue: The Tale of Data Integrity

In the grand theater of databases, both MySQL and NoSQL play their roles in maintaining ACID principles, each with its script and style. MySQL is the meticulous librarian, ensuring every 'i' is dotted, while NoSQL is the free-spirited artist, painting data in broad strokes.

Choose your cast depending on your play – whether it's a strict drama of data integrity or an improvisational skit of flexible storage.

And thus concludes our saga of ACID in databases, a tale of commitment, consistency, and a bit of controlled chaos!