The schema is the thinking

My blog database has 41 properties. Two of them are called Status.

Not Status and Stage. Status, and Status 1. The first one has 23 options I added by hand over about a year, including one called TEMPLATE, one called Convert to Social Post, and one just called delete. The second has the three options Notion hands you for free, and across 497 rows I have touched it exactly once.

I know why the first one exists. I have no idea what I was doing with the second.

Most people treat a database like an organized filing cabinet. A place to put things so they don't get lost. That's a low ceiling, and the better use is sitting right there: a database schema is a theory. Every property name is a claim. Every relation is an assertion about how two things connect.

I believe that. I also have two Status columns.

The template is a shortcut around the thinking

Most people skip to storage. They copy templates because building from scratch requires them to answer questions they haven't thought about yet.

Which sounds a little bit like an insult, and I don't quite mean it as one. I copy templates. A template is somebody's finished answers arriving without the questions attached, and it works about as well as their situation is close to yours, which is a pretty wide range. A client intake form a friend built for the same kind of client I have is close to a sure thing. A Life OS is more of a coin flip.

So the failure isn't using one. It's that using one is silent. Nothing in the interface tells you which decisions you skipped, so you don't find out until the day you ask the structure a question and it just sits there.

Five of my columns are dead and I can name them

Fine, my own tables, since I opened with them.

I have a Categories relation and a separate Blog Category relation, pointing at two different databases. I have a Keywords relation and a Keywords to Rank For text field. I have Styles, and I have Style Inspiration. I have five numbered image prompt fields, which is a number I picked once and never went back to.

Of the 41 properties, 33 are filled in on more than five rows. Five are dead: Styles has one entry across 497 rows, Status 1 has one, Voice Mode has three. Each of those is a moment where I changed my mind about what a blog post is and never came back to clean up after myself.

There's a feeling I don't have a good word for, when you open a table you built and find a column you cannot remember deciding on. It isn't regret. It's flatter than that. It's reading a note from somebody who knew something you no longer know.

The thinking doesn't survive in the schema

Which is where my own claim starts to come apart a bit.

Peter Naur wrote a paper in 1985 called Programming as Theory Building, and the argument is that a program is not the code. The program is a theory living in the heads of the people who built it: why it's shaped this way, what the boundaries are for, what would break if you moved one. Then the line that does the damage. Program revival, "that is reestablishing the theory of a program merely from the documentation, is strictly impossible."

If that's right, and I think it mostly is, then the schema is not the thinking. Building the schema was the thinking. The schema is what's left over once the thinking has evaporated out of it.

So what was I doing for the year I spent adding those 23 status options? Thinking, I'd say. And what do I have now? 23 status options, four of which I could not explain to you without opening the database and guessing.

That does reframe the template problem, though. A template doesn't fail because it's generic. It fails because it's a fossil, and you can't revive a theory from a fossil no matter how good the fossil is. You can only build your own next to it.

Honestly.. I don't know whether that makes the exercise worth more or less. Worth more, I think, if you expect to keep rebuilding. Mostly a waste if you build it once and expect the structure to go on being smart for you.

Sometimes the filing cabinet is the correct call

The strongest argument against everything above is that thinking has a maintenance bill and you pay it forever.

Tiago Forte makes it directly in the PARA essay: "if your organizational system is as complex as your life, then the demands of maintaining it will end up robbing you of the time and energy you need to live that life." Four folders, applied to everything, no bespoke thinking required. That's a real position held for real reasons and I don't have a clean answer to it. Anyone who has built a real system has hit the week where maintaining it costs more than it gives back. It happened to me, which is why a few of my databases have the word archive sitting in the title.

The way I've ended up splitting it, and I'm not sure it generalizes: I build the schema when it's a domain I'll be inside for years and one where I'm the person who decides what the objects are. I take the template when it's somebody else's solved problem and I just need the thing filed. Most of a CRM is the second kind. Most of my own work is the first.

Four minutes on your own database

Open the one you use most and sort the properties by how often they're filled.

Count the dead ones. Anything filled on under five percent of your rows. Not a mistake by itself, but each one is a decision you changed your mind about and didn't finish.

Find the duplicate pair. Two fields covering the same ground under different names, like my Keywords and Keywords to Rank For. You built the second one because the first stopped answering. The question is which one you actually use now.

Look for the number you picked once. My five image prompt fields. Some cap you set on a Tuesday that has been quietly shaping the work since.

Then the real one. Point at any property and say out loud why it exists. Not what it holds, why it exists. The ones where you hear yourself guessing are the ones where the theory has already evaporated and only the column is left.

Whatever you can't explain, you can delete or you can rebuild. Both are fine. Leaving it there is the only move that costs you something, because next year you'll open the same table and read the same note from the same stranger.

Did building it require you to think differently about the thing you were organizing? If it didn't, you copied a template. You didn't build infrastructure.