This editorial was originally published on Aug 21, 2019. It is being republished as Steve is coaching volleyball in Utah.

A long time ago I read a book called The First Law. It's a legal thriller, and I'd recommend it. It has nothing much to do with databases, but I was reminded of the book and the rules of any particular process when I saw a post called The First Database Rule.

The post is from Seth Godin, who is really a marketing individual, but I do think his rule makes a lot of sense for clients. I also think that as both developers and database professionals, we forget that most of our clients would prefer to have our systems follow this rule: it should be as simple to fix an error as it is to make one.

I've worked in many systems, and with many people, that expect data entry or loads to go perfectly. They expect things to work and want to blame the process, the person, the file, or something else when something doesn't work well. What might be worse sometimes is that we expect some data in the database to be immutable, like a PK, assuming that clients will have and enter all the correct data at once. Most of us do allow changes in our databases, but we don't make it easy, especially if it's a piece of data like a primary key.

This is one reason I dislike many natural keys as PKs. We make mistakes when we enter them. Heck, I've probably typed my name a million times on a computer keyboard, and I still make mistakes. Even in data entry forms. What's worse, I have some auto-fill selections in my browser that are incorrect and I'll select the wrong one at times.

Fixing mistakes ought to be easy. We ought to expect that we will get data wrong. We'll load it wrong, we'll transform it wrong, and our DBAs will type corrections wrong. Design the system to account for mistakes and ensure that problems can be quickly fixed. Whether by a client or a sysadmin.

Agility ought not to be just how quickly we can change the software. It needs to include the ability to change the data, which is the most important part.