Setting FK Constraints in Data Modeler

Posted on February 11, 2026 by way0utwest

One of the things a customer asked recently about Redgate Data Modeler was how to set a FK constraint between two tables. The tool seemed to make it easy, but they encountered a few errors. Here is how this worked for me.

This is part of a series on Redgate Data Modeler.

Adding a Constraint

This might make more sense in the video walkthrough, but here’s the text version. I want to add a constraint to my model that links the Organization and User tables shown below. This is a 1 (Organization) to many (User) FK.

2026-02_0104

I don’t have a good FK yet in the child table (User), but that’s OK. I’ll click the Add new reference icon in the upper left of the design surface.

2026-02_0105

Once I do this, I can click on the Organization table and drag to the User table. That will give me this view. Note that this defaults as a 1:n relationship, so you want to start with the parent. There also is a new “Organization_OrganizationID” column added as a FK.

2026-02_0106

That’s not a bad pattern, especially with modern Intellisense, where I don’t need to type everything out. This lets me know where the join should be. However, for many of us, we prefer having something simpler, like OrganizationID as the column in the child.

If I want to change this, I can look to the right for the Reference Properties. Note the default name below is User_Organization, which I definitely don’t like.

2026-02_0107

I can adjust the name to meet my standard, which I’ll do. I can also adjust the FK column, but I’ll need to go to the child table, User, to do this. If I rename that column there, I see this.

2026-02_0108

When I click back on the reference, I see this. My change for the FK table is there, but the Primary has defaulted to OrganizationName. Fortunately, there’s a drop down where I can change this.

2026-02_0109

Below this, I have other properties. There’s a color (if you care), but also I can set cascading actions. See the drop down below and the options. These can be set for update or delete. There is also the additional property to set this as not for replication.

2026-02_0112

Once I do this, the changes are saved. If I generate the SQL script, I can see my FK exists inside the script. You can see the relevant portion below.

2026-02_0113

Summary

Setting accurate FK constraints is an important part of data modeling. I certainly see the reasons why some people don’t like FKs, but if you set them, you want them to be accurate. Redgate Data Modeler supports this, but it’s not as straightforward as I like. Hopefully that changes over time.

I don’t know that the names matter that much, but in case you are concerned about naming, you can customize this.

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

Posted in Blog | Tagged , , | 2 Comments

Webinar: Navigating the Database Landscape in 2026

Posted on February 10, 2026 by way0utwest

For a number of years, we’ve produced the State of the Database Landscape report, based on surveys and research we do every year. I have found it very interesting to see how people respond and what we learn from the report each year.

This year is no different, with one change; we’re doing a webinar. Register to hear the advocates talk about navigating the database landscape in 2026. Grant, Kellyn, Pat, and myself are set to sit down and discuss the findings on Feb 18 at 1200pm EST.

We reviewed the report and now each of us is digging in to those areas we are most interested, and we’ll express our thoughts in the webinar. With over 100 years of database experience between us, we hope you’ll enjoy it.

And we are ready to take your questions and discuss and debate the future of our industry.

Register today and I’ll see you on Feb 18.

Posted in Blog | Tagged , , , | Comments Off on Webinar: Navigating the Database Landscape in 2026

Aging Code for T-SQL Tuesday #195

Posted on February 10, 2026 by way0utwest

It’s that time of the month again, with T-SQL Tuesday coming along. I managed to not forget about this and checked with the host. He had an issue, but fortunately I got a friend to step up.

This month Pat Wright has an interesting question, asking how your code has aged. He and I have had a few conversations lately about getting older and when I asked him to host, this was a perfect choice.

I’m definitely getting older, but what about my code?

25 Years Later

Actually a little more, but I wrote a series called “Tame Those Strings” for Swynk a long time ago. That became Database Journal, but during the switch, they stopped paying us authors. A few of us started SQL Server Central and we went live 25 years ago.

In that piece, I referenced the oldest article, which is Tame Those Strings Part 4 – Numeric Conversions. There’s also a part 3, but in those pieces, is that code still useful?

A bit.

These are basic articles looking at string functions that are still heavily in use today. The idea of cleaning phone numbers using REPLACE is still something we might do today. If we are using SQL Server 2025, there are additional functions, but I still see a lot of code that still use multiple CHARINDEX+SUBSTRING or REPLACE functions.

I asked the Prompt AI if it could do better.

2026-02_0091

It gave me two pieces of code. The first is nested REPLACE() statements. This works, but I find this hard to read. I’d rather have separate statements, for ease of maintenance.

2026-02_0095

The second is a single statement, using a CASE and STUFF and XML to clean things. I like this, thought it’s a semi-complex way of doing things. However, it works.

2026-02_0096

Has the code aged well? I think it’s OK. There are better ways, as shown with the STUFF/XML version, which wouldn’t have worked in SQL Server 2000. Still, the use of REPLACE is a common technique still used today.

For part 4, with the use of LTRIM and STR(), today we have FORMAT, which is cleaner. However, it’s likely less performant. In a simple test of 500,000 values, the FORMAT takes over 600ms to return the results while my LTRIM/STR combination consistently runs in the 460ms or quicker range.

I think my code aged well.

Posted in Blog | Tagged , | 1 Comment

The DBA is Dead; Long Live the DBA

Posted on February 9, 2026 by way0utwest

I remember getting a job at a startup in the Denver Tech Center. This was shortly after SQL Server 7 was released, with a marketing campaign that the platform was auto-tuning and wouldn’t require a DBA. My colleague asked me if I wanted to learn Cold Fusion and have a longer career. I declined and stuck with this SQL Server thing, which has seemed to work out pretty well over the years.

I was reminded of this when I saw a “Death of the DBA Again” post, this time from an Oracle DBA. There are plenty of links in there from Larry Ellison and Oracle about how some version of Oracle won’t require a DBA. I’ve seen questions on Reddit (and elsewhere ) about this topic where people seem to think DBAs can be replaced.

Or maybe they want them replaced.

There are no shortage of posts on why this isn’t the case (Grant, Kellyn, Brent, William, Boris). These all look slightly different, but the main thrust is that there is still data management-type work and people are needed to do it. Or maybe to direct the AIs to do it.

An interesting post from Kendra last year that we will see less DBA jobs because good DBAs can leverage AI to replace a few less-good DBAs. I like her approach, and the key reason why AI agent usage will grow is that they can potentially just make less mistakes than a human.

If that human making mistakes is you, then you might not have a job.

I do think that the DBA as a gatekeeper or a single point of managing systems and ensuring backups/security/patches are made is dwindling. However, there are still lots of places for database-related work. High Availability setups are needed; someone has to work with InfoSec and auditors and implement their requirements. That might be especially important as those requirements might not be clear and clean enough for all your systems. While ETL might be a thing of the past with the various “links”, without a doubt, people will link too many tables to analytics systems, leading to overloaded systems, too many resources being used, and costs being too high.

That might be a reason we will still need some type of DBA. They need to field the complaints from budget holders and work on resolutions to reduce costs.

The DBA will continue to exist in many organizations, but the job will change, and you need to evolve. There might be other organizations that don’t want a “DBA” as a title, but they will need a data engineer, a full-stack developer spending more of their time on the database stack, an InfoSec person that mostly works on database security, or some other job that absorbs all the data-related chores.

There is a lot of opportunity still out there, but the bar is being raised, and one end of that bar rests on AI. Improve your skills, show your value, and become someone who delivers results and doesn’t just say “No.”

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 | 2 Comments