Expanding into Print

This is part of a few memories from the founders of SQL Server Central, celebrating 25 years of operation this month.

When we started SQL Server Central, our goal was to build a great resource that helped other people advance in their careers and also made some money. Our decisions in building the site were based around the digital world and treating the community as we would want to be treated. Over time, however, we realized that continuing to grow this business was hard in a digital-only world. We experimented and proposed helping others build similar sites, like ReportingServicesCentral (which would have been great) or NotificationServicesCentral (which would not), but ultimately, we weren’t experts enough in those areas and couldn’t find people willing to partner.

Everyone thought they could do it themselves and that the knowledge was the hard part, and execution was easy. The truth is that the reverse is the way it works.

In any case, there was a point in time when we were sending 6 newsletters a week (Monday through Saturday) and we didn’t think there was much room for growth there. Andy suggested that we compile all our articles into a Best of SQLServerCentral book. I didn’t think they would sell well (they didn’t), but we did enjoy giving them away at our annual SQL Server Central Party at PASS. We even added a second series where we compiled the Question of the Day series into books, based on the Two Minute Mysteries I read as a child. We called them SQL Server Stumpers. Those were hard to manage, and were multi-month long projects that I had to toil away at almost every week.

Then came the magazine: SQL Server Standard.

In the early 2000s, the Professional Organization for SQL Server was trying to grow as well. We knew magazines were popular and profitable back then, so we proposed helping them produce a magazine every other month (6 times a year). They were charging an annual membership fee and needed to give members more value, so we agreed to produce, publish, and ship a magazine to all their members. It was both a source of tremendous stress for me to manage, as well as a proud item I could point to every month.

I wish I had some online links, but this was intended to be a real-world, analog item. We hoped it would grow to be a substantial revenue item, but it never did and PASS shut it down after around a year of publication.

I was glad because these projects were a never-ending source of stress. Managing book projects that were 4-6 months, along with the every-other-month magazine, and a daily newsletter was overwhelming at times.

Our forays into the print world provided me with a lot of education about how books and magazines work, and gave me a few mementos.

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

The Book of Redgate: SQL Server Central

It was neat to stumble on this in the book, a piece by me, just a few years after Redgate acquired SQL Server Central. I’ll let the words speak for themselves.

2026-01_0142

2026-01_0143

I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.

Posted in Blog | Tagged , , | 5 Comments

The Power of Data and Privacy

I tend to be fairly careful with data, especially data on this site. When we started the site, we were worried about potential issues and worked hard to ensure we kept our systems safe and limited the attack surface area for personal information. We also declined the various offers we had to sell our list of subscribers to marketing firms. We know that some places add value for marketing, but some abuse the trust of their users and our approach was always to be careful.

When we sold the site to Redgate, we emphasized the need for this trust, and to date, Redgate has been a great steward of your personal information. I regularly field requests for uses of data from other marketing people, and almost all get declined. I’ve had a number of great managers who have supported me on this because we value your privacy.

Recently I saw a piece from Troy Hunt, asking who deserves privacy. He runs HaveIBeenPwned, which tracks data breaches. There have been some sensitive breaches, like the Ashley Madison breach, and he has decided to handle some of those differently. I appreciate that, even though I don’t visit any of those sites, I do think there can be unintentional consequences from revealing too much data.

We certainly have plenty of problems with public data, which was never intended to be accessed at scale. Once someone can query lots of data from one place, they can correlate and use it in ways we never imagined.

In the piece Troy notes that he has been attacked by some people because he has chosen to redact certain information. This is censorship of a sort, but a) this is a private site, and b) there are good intentions. This service was never intended to be a weapon, and I agree with that. I have rarely censored anyone at SQL Server Central, but it has happened when someone becomes harassing and unprofessional. Our forums are great for civil debate and disagreement, but not for personal attacks.

I am glad for the restrictions that the GDPR and similar legislation has placed on how companies used data. It has made many individuals and organizations more responsible with how they handle data internally. It hasn’t necessarily helped with data breaches, but at least there are less intentional abuses.

Data has tremendous power at scale and my view is similar to Troy’s: we all deserve some level of privacy.

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

Setting FK Constraints in Data Modeler

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 , , | Leave a comment