Life Before Databases

Lora runs the Marquee, a two-screen neighborhood cinema, and for its first year she ran it the way almost every small business starts: a spreadsheet. One sheet listed the films, one listed the showtimes, and a notebook by the register held the bookings. It worked. It kept working right up until a busy Saturday evening, when two volunteers at two laptops sold seat G7 for the 8 p.m. show to two different people — and Lora spent the intermission apologizing with free popcorn.

This page is about why that keeps happening. Not because anyone was careless — because the tool has no defense against it. Every idea in this book exists to fix a specific way that files and spreadsheets fail, so before we meet the fix, it is worth seeing the failures clearly. They arrive on a schedule, and they arrive for everyone.

Files and Spreadsheets Are Fine — at First

Let's be fair to the spreadsheet: for one person and a small amount of data, it is a genuinely good tool. You see everything at once, you edit anything with a click, you can sort and sum, and everyone already knows how to use it. That is exactly why every business starts there. If the Marquee had stayed a one-person operation selling forty tickets a week, the spreadsheet might have been enough forever.

The trouble is not the spreadsheet itself. The trouble starts when the data becomes shared — more people, more sales, more questions — and the comfortable tool quietly turns into a source of problems that no amount of care can fix.

The Failures Arrive on Schedule

The double-sold seat was the first failure: two people editing at once. Both volunteers opened the bookings sheet, both saw G7 free, both wrote a name into it. Whoever saved last won, and the other sale silently vanished. Nothing warned anyone. The spreadsheet is built for one pair of hands; give it two and it simply loses one of them.

The second failure followed within a month: copies drifting apart. Lora emailed the film schedule to her staff, then changed Tuesday's showtime in her own copy. Now two versions of the truth existed, and the one taped to the staff-room wall was the wrong one. Files named schedule_FINAL_v3 are the fossil record of this failure — everyone has seen them, everyone has made them.

The third failure is quieter: nothing checks what you type. One evening a tired volunteer recorded a booking for seat "Gs7" — a seat that does not exist. The spreadsheet accepted it without a blink, the way it would accept a showtime of "25:00" or a price of "twelve euros". Every cell takes anything, so every typo becomes stored fact, waiting to confuse someone later.

And the fourth failure grows with the data: slow answers to fair questions. "How many tickets did Night Bus sell this month?" is a completely reasonable thing for Lora to ask about her own cinema. With bookings scattered across sheets and a notebook, answering it means an hour of scrolling, filtering, and hand-counting — so the question simply stops being asked.

Both open the sheetG7 looks free to both

→

Both write G7two names, one seat

→

Last save winsone sale vanishes

→

Two tickets, one seatfree popcorn time

What the Fixes Have in Common

Look at the four failures again and a pattern appears. The double-sale is about sharing — many hands on the same data at the same time. The drifting copies are about sharing too: there should be one truth, not a family of versions. The phantom seat "Gs7" is about structure — the data has rules ("seats look like a letter and a number"), and the tool does not know them. And the unanswerable question is about getting fast, reliable answers from data you can trust.

Shared, structured, trustworthy. Hold on to those three words — they are the spine of this entire course. Every failure Lora hit is the absence of one of them, and each one is impossible to fix with discipline alone. Two careful people can still overwrite each other in the same second; care does not scale. The fix has to live in the tool.

Where We're Going

There is a tool built around exactly those three words. It holds one copy of the data that many people can read and change at the same time without losing each other's work. It knows the rules of the data and refuses entries that break them. And it answers questions about thousands of rows in less time than it takes to blink. That tool is a database, and the next page pins down precisely what it is — including the part of it that does the guarding.