Poor Names

Posted on April 13, 2026 by way0utwest

It’s always interesting to me when I give product feedback to engineers at Redgate on their demos. Quite often they’ve built a feature that uses AdventureWorks or Pagila (PostgreSQL) or some other well known schema to evaluate how their particular thing works with a database. I try to remind them that many databases aren’t well modeled and designed with consistent naming.

I ran across a Daily WTF article that isn’t showcasing databases, but it does show some poor naming in data being stored in a PDF. The developer who had to automate a process had to map these fields to database fields, which also might not be named very clearly. In fact, I think I’ve seen a few database models that used column names like the field names in the PDF.

Most systems we work on evolve over time. They aren’t built by one programmer, or one team, across any period of time. Existing developers leave and new ones start. DBAs change, and we often don’t have any code analysis rules enabled or running in CI that might help us with consistency.  Often we don’t even have our rules documented.

Humans are amazingly creative beings, but they also get very uncreative when they have to repeat that creativity over and over. It’s why we find a neighborhoods in Colorado with Pine St, Pine Ln, Pine Rd, Pine Circle, Pine Way, etc. You get the idea. Someone got bored and didn’t want to be creative, so they just took the easy way out.

The same thing happens in databases. I’ve seen people have a Customer table and then a CustomerDetails table alongside it (singular and plural) with a custDefault (case) and a tblCustContact (prefix) table that leave me scratching my head. Did the next developer not look at the database at all? Certainly they didn’t use any modeling tool like Redgate Data Modeler.

I don’t blame others, since I’ve found myself struggling to be creative as well as consistent when I build systems. Sometimes I’ve got some automation running that reminds me to do better, but often I’m depending on another human to catch these inconsistencies in a code review. However, I’m not sure code reviews include looking at the name of the object for most people. Well, maybe column names, but that might be it.

I’d hope an AI system could recognize poor names and then suggest better ones that capture the intent of the data being stored and look like the other objects in the database. Unfortunately, that will likely lead to a section in the database that looks amazing while all the older objects drive you crazy with their random nature. Maybe the AI can at least update the comment or description fields in code to ensure there’s some place to look for information to help us do better in the future.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | Leave a comment

Changing the Cardinality of a FK in Redgate Data Modeler

Posted on April 13, 2026 by way0utwest

One of the things a customer asked recently about Redgate Data Modeler was how to adjust a FK constraint between two tables. The tool seemed to makes this  easy, and this post will show you how.

This is part of a series on Redgate Data Modeler.

Altering a Constraint

In a previous post, I looked at adding a FK. Let’s do things a little differently here. Let’s change a constraint to better reflect the relationships between entities. In this case, let’s look at a part of my model. I have the User and Author entities linked as shown below. Note that we have a User with a 1:many relationship to Author.

2026-04_0213

This isn’t correct. A User cannot be a part of multiple authors. This is, logically, a 1:1 relationship. Each Author is related to one and only one User. Each User can be an author, but only one Author. So let’s fix this.

If I click on the relationship, it turns blue and highlights.

2026-04_0214

On the right side, the properties pane displays the relationship properties. Note that there is a relationship type below the comment.

2026-04_0215

If I click the  drop down, I can change this to whatever cardinality makes sense.

2026-04_0216

I’ll choose one to one. When I do that, I can see the diagram changes.

2026-04_0217

I can also change this for other entities. Here I have a One to Many, but this is really a many to many relationship. So I need to change it.

2026-04_0218

I can adjust the properties in the drop down and you can see both the diagram and the right properties pane match.

2026-04_0219

Summary

We may model our entities incorrectly, either because of incomplete information or simple mistakes. In any case, if you need to change cardinality in a relationship, it’s easy to do in the relationship properties.

Give Redgate Data Modeler a try and see if it helps you and your team get a handle on your database.

Video Walkthrough

Here’s a short video of my working with Redgate Data Modeler and changing cardinality.

Posted in Blog | Tagged , , | Leave a comment

Acting with Confidence

Posted on April 10, 2026 by way0utwest

Recently, I saw a graph about making decisions that showed the impact of both reversibility and consequences. Here is an example of such a graph and how one might approach decisions. If things are easily reversible or have a low consequence, we tend to make a decision and move on. Or we are willing to make a decision. One of the examples of such a decision was choosing what to wear out to dinner. It’s easy to change, and (in general) of little consequence. Choosing to send a large amount of money to someone through Venmo (or some other mechanism), can be hard to reverse and have substantial consequences.

This made me think of some of the DBA and developer decisions I’ve made in the past. When we work with databases, the changes we make can have a large impact and be quite consequential to our organization. Downtime, data quality, etc. could all impact revenue, profit, reputation, or even future prospects of survival. That can be a lot of pressure when you are deciding to refactor a data model or adjust a lot of data during a deployment.

We might think we can rollback or undo changes, but often we would end up applying reversing transactions. If I change a data type, the data is changed ( assuming the DML completes). To change back, I can’t roll back outside of a restore. I would change the type back and have an equally large and long transaction run. Having HA or replication technologies in the mix can dramatically impact the scope of both the initial and reversing transactions.

How confident must you be in your actions before you undertake something of consequence? Do you require an easy rollback, or are you willing to act even if the rollback is painful?

Maybe a better question is how do you appraise the consequence of an action? Is it the application/database or perhaps the data? You might consider all the dependencies from other applications or pipelines on this. I know many DBAs worry about the performance impact of changes that can slow or stop other work. I constantly see people asking if Flyway can estimate how long a change will take, especially when dev/test environments are a poor representation of production sizes, scales, and workloads.

If you have a 2GB database, you might just make changes. A restore is quick, and I’ve often found greenfield applications taking this approach since the data sizes are small and even consequential actions can be undone with a restore operation. Many of the “code-first” technologies work great in these situations, but once we have multiple application dependencies and large data sets, restores can be non-trivial or even unacceptable ways to deal with issues.

The image linked above talks about gathering data and analyzing, which sounds like the prudent thing to do, but this can be easier to say than do in practice. Deciding what analysis to undertake and how long to spend on it are the real tricks. Those are the judgment calls that only experienced humans can make. While AI might help, this is an area I really want capable humans with the final say.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | Leave a comment

Advice I Like: Rewards from Work

Posted on April 10, 2026 by way0utwest

The greatest rewards come from working on something that nobody has words for. If you possibly can, work where there are no names for what you do.” – from Excellent Advice for Living

I work for a software company, trying to sell tools to companies for database work. It’s not hugely rewarding. I enjoy it, and I like going to work. I like the colleagues and customers, but this doesn’t fill my soul.

I’m an average person and while I’m good at what I do, I don’t make huge differences. I make small changes, both at Redgate and while coaching. The latter is way more fulfilling to me. I coach at a small club, not the top one, we don’t make news locally, but I help and watch kids grow up before my eyes in many ways.

I love that.

The saddest thing I’ve seen across the last 30 years of my career is how many brilliant people have moved to work in finance and tech (including biotech), aiming to win the lottery with options and IPOs rather than spending their efforts on making the world better. Their focus is on clicks and trades, not bettering science, knowledge, or anything for humanity.

Lots of people do great work still, but many of the brightest of my generation and the next aren’t focused there.

I’ve been posting New Words on Fridays from a book I was reading, however, a friend thought they were a little depressing. They should be as they are obscure sorrows. I like them because they make me think.

To counter-balance those, I’m adding in thoughts on advice, mostly from Kevin Kelley’s book. You can read all these posts under the advice tag.

Posted in Blog | Tagged , | 4 Comments