Building With AI
From Spreadsheet Thinking to a Real Database: What Surprised Me as a Non-Programmer
Published 24 August 2026
A database can look like a set of sheets until you try to connect people, companies, areas, and movements without breaking the history. The surprises were structural, not cosmetic.
A sheet is a view. A table is a rule.
In a spreadsheet you can type anything into the next empty cell. If two rows describe the same person slightly differently, you can still read the file. A database used by a web application is less forgiving on purpose. Each kind of thing — a person, a company, an area, a movement — tends to live in its own table, with a stable ID rather than “whatever text was in column A.”
That felt like extra ceremony until the same company name appeared in more than one way, or a movement needed to point at an area that might later be renamed. The ID stays. The label can change.
Relationships replace copy-paste
A movement record should not paste a full copy of the person’s name, company, and area into every row as if it were a printout. It points at those records. That pointer is a relationship, often described as a foreign key: this movement belongs to this user and this destination area.
The benefit is consistency. The cost is that you cannot treat one table as independent. Change a company, and every user pointing at it is affected. That is not a software quirk. It is the same problem as updating a name in one tab of a workbook and forgetting the other tab, except the application will not let you pretend the tabs are unrelated.
Permissions sit next to the data
A shared spreadsheet is often protected by “who has the link” or “who has the file.” A hosted database can enforce permissions per table or per row. That is why a public website can show occupancy summaries to an administrator after login, without offering the same data to whoever opens the scan page.
I had to learn that the website and the database are not one lock. If only the page is locked, someone might still ask the database another way. Row Level Security is one of the names for that second lock.
Deleting is no longer clearing a cell
In a sheet, deleting a company row is easy and dangerous: the history of who belonged to that company may vanish or become a broken name. In a live occupancy system, users, movements, and later recovery can still need that company information.
So “delete” becomes a set of questions. Are people still assigned here? Should the name remain on old movements? Is this a hidden system row that should never be removed because the application uses it internally? A feature that looked like a simple dropdown — choose a company, or type another name — turned out to be a data-design problem, not a cosmetic form problem.
History is a feature, until you try to tidy it
Occupancy is a current picture built from past movements. If you rewrite history to make the current picture prettier, you lose the ability to explain how you got there. Production data is the data people already depend on. Experiments that were safe on a copy of the database are not automatically safe on that live set.
The surprise was not that databases exist. It was that a construction occupancy idea immediately needed tables, IDs, relationships, and a cautious attitude to deletion. AI could help write the SQL. It could not tell me which records still mattered. That decision stays with the person who understands the site problem, which is where the first-app story and the security story meet.