Welcome to Client-Server Databases!

In this chapter, we are going to explore how big databases handle thousands of people using them at the exact same time. Whether you are booking a concert ticket or checking your bank balance, you are using a client-server database. We’ll learn how these systems work and, more importantly, how they stop data from getting messy when everyone hits the "Save" button at once. Don't worry if this seems a bit technical at first—we'll break it down piece by piece!

1. What is a Client-Server Database?

In a simple database, one person might be using a file on their computer. But in the real world, many people need to see and change the same information. A client-server database system provides simultaneous access to a central database for multiple clients.

Think of it like a professional kitchen: The Server is the head chef who stays in the kitchen and manages the pantry (the database). The Clients are the waiters (apps or users) who send in orders (requests) for food. Multiple waiters can send orders at the same time, and the chef has to make sure the pantry doesn't run out of ingredients without anyone noticing!

Quick Review:
Client: The application or user that requests data.
Server: The powerful computer that stores the database and handles requests.
Simultaneous Access: Many people using the database at once.

2. The Problem: Concurrent Access

When multiple users try to change the same piece of data at the exact same time, we call this concurrent access. This leads to a famous problem called the lost update.

Imagine this scenario:
1. User A and User B both see that there is 1 pair of shoes left in an online shop.
2. User A clicks "Buy." Their computer says "There was 1, now there is 0."
3. At the exact same microsecond, User B clicks "Buy." Their computer also saw 1, so it also says "There was 1, now there is 0."
4. Both updates are saved. The shop has sold 2 pairs of shoes, but they only had 1 in stock! One of those updates has "overwritten" the other, causing a lost update.

Key Takeaway: Without a way to manage concurrent access, a database loses its integrity (it becomes inaccurate and unreliable).

3. How to Manage Concurrent Access

To keep the data safe, the server must use "Concurrency Control." The AQA syllabus requires you to know these four main methods:

Method A: Record Locking

This is the most common method. When a user starts editing a record (a row in a table), the server "locks" it. No one else can edit that specific record until the first person is finished.

Analogy: It’s like a public toilet cubicle. Once you go in and lock the door, no one else can get in until you leave.

The Danger: Deadlock
Sometimes, User 1 locks Record A and waits for Record B. Meanwhile, User 2 has locked Record B and is waiting for Record A. They are both stuck forever! This is called a deadlock.

Method B: Serialisation

Serialisation ensures that transactions are processed one after another, rather than overlapping. Even if requests arrive at almost the same time, the server forces them into a queue so that the second transaction can only start after the first one has completely finished.

Method C: Timestamp Ordering

Every time a transaction starts, it is given a timestamp (the exact time it arrived). If two users try to change the same data, the server looks at the timestamps. The one with the earlier time gets priority. If a later transaction tries to access data that an earlier one is currently using, the later one is usually told to wait or restart.

Analogy: Like taking a ticket number at a deli counter. It doesn't matter how loud you shout; the person with the lowest number on their ticket gets served first.

Method D: Commitment Ordering

This method looks at the whole "transaction" and decides the best order to save (commit) them based on their impact on each other. It ensures that if one transaction depends on another, they are finished in an order that doesn't break the rules of the database.

Did you know?
In high-speed banking, these decisions happen in milliseconds! Database administrators have to choose the right method to balance speed and safety.

Summary and Memory Aid

To remember the four ways to control concurrent access, just remember L.S.T.C.:

L - Record Locks
S - Serialisation
T - Timestamp Ordering
C - Commitment Ordering

Memory Trick: "Large Servers Treat Clients"

Key Takeaways for the Exam:
• Client-server databases allow multiple users at once.
Concurrent access can cause lost updates (data integrity issues).
Record locking prevents others from editing while a record is "in use."
Serialisation, Timestamps, and Commitment Ordering are alternative ways to keep data organized and safe.