SQL Server on Linux was released with version 2017. Since then, I’ve seen some deployments of SQL Server on Linux, but many of the customers I work with still deploy SQL Server on Windows. While there are limitations and unsupported features, most of what we need is available in SQL Server on Linux.
I assume most of you out there work on Windows machines against Windows servers. Maybe some of you run containers, but that’s likely a minority. Windows seems to have won the desktop and for most of us running SQL Server, the server room as well.
However, if you use containers, you likely use Linux ones since SQL Server isn’t supported on Windows containers. I know I do, and I like them, but overall, I find I need to know very little Linux to do my job, or even work with the containers.
I like Linux. As someone who learned Unix early on and installed Linux 0.8, I thought at one point I’d spend most of my career in that world. Especially as I worked with DOS and Windows 3.1 in corporate work and found them much less capable. I still remember writing grep.bat and awk.bat files to duplicate some of the things I did in Unix on DOS machines.
For doing database work, most platforms are ported to Windows, but even if you connect to an Oracle/PostgreSQL/MySQL/MongoDB/etc. system running on Linux, do you need much linux? I find that ls, pwd, and cat get me through most of the things I need to do. When there’s something more complex, like sudo systemctl restart mssql-server, there are plenty of code snippets in the docs or some website. These days, you could even ask an AI how to do many simple tasks.
If you don’t use Linux, then you don’t need any, but if you deal with any sort of system running on Linux, how much is important to know? What’s your top ten list of things a newbie should learn? Let us know today.
This is incredible advice. I think that much of the complaints about the US from the rest of the world is how transactional we are. Whether this is with stuff we buy or neighbors or how we eat dinner or how we treat sports, we’ve often become transactional. What’s the best, fastest, easiest, most convenient, etc. We often want a quid pro quo for things we do.
When you spend more time with others, when you value the experience and what you get from it, life is better.
It can be harder, slower, etc., but I think it’s better.
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.
I don’t know how many of you will be disappointed or impacted by this, but Azure Data Studio (ADS) is being retired, as of 6 Feb, 2025. It will be supported for a little over a year, until 28 Feb, 2026. On one hand I’m not surprised, and on the other, I’m a little shocked by this.
I have written a number of articles on ADS, and shown how things work, as well as pointed out a number of things that don’t work well in the product or its extensions. These pieces have gotten a number of reads, and people have commented on them, so I wonder if there are a lot of you that are upset by this. Is this going to change the way you work? I will say that it will lightly change my work, as I do use ADS to connect to PostgreSQL, but not so much for SQL Server.
I have tried to use ADS, but I just don’t like it. I don’t have a good reason, as it does a lot of what I need from a query tool. I think the port of the query and result experience from a real app like SSMS or Enterprise Manager or even isql/w is just a worse experience. I don’t like the ADS interface and it’s annoying to me.
I suspect that many others feel the same way (other views from Deb and Kevin). They don’t like the ADS experience and prefer SSMS or some other tool. I know there’s been no shortage of complaints over the years about, and finally MS has listened. From first trying to get everyone to leave SSMS to forcing people to install ADS alongside SSMS and now to finally retiring the tool. I think it’s a good decision as people don’t want to lose SSMS and it’s hard to maintain two tools.
We will still have VS Code, which I use often for other purposes. I haven’t spent much time with the mssql extension, but I need to as it’s been updated as of a few months ago and supposedly works better now. We’ll see.
In the meantime, I won’t mourn ADS. It was a tool that had potential. I liked the idea of notebooks, I liked the fast startup. I just wish it were better implemented as a run-a-query-and-get-results application. I wish we had a cross platform editor that was simple and fast, but not one based on VSCode. One that’s written to just manage queries. Maybe they’ll rewrite isql/w in a modern way and port it to Linux.
A previous post showed how add starting tables for the subsetter to look at, however that didn’t get me a good data set for testing. This post continues looking at the subsetter by adding manual relationships to our configuration.
In my previous post, I’d picked a starting table and had reduced the dbo.players table from 16564 to 1800. However, I only had player information. If I query my subset database, I see there is a player, but I have no batting statistics for this player.
This is because my table has no declared FKs in it. If I check the dbo.batting table, I can see only a PK.
Let’s fix this.
Declaring Manual FK Relationships
In the options file documentation, there is a section that notes manual relationships can be declared with a key called “manualRelationships”. If I copy/paste the example section into my options file, I’ll see this:
I don’t have a SourceTest table, so let me edit things. I’ll set a relationship between dbo.players.playerID and dbo.batting.playerID. This gives me the following in my options file.
Before I run my subsetter, here are the row counts by table.
I’ll re-run this subset command, which includes my option file at the end.
rgsubset run --database-engine=sqlserver --source-connection-string="server=localhost;database=BB_FullRestore;Trusted_Connection=yes;TrustServerCertificate=yes" --target-connection-string="server=localhost;database=BB_Subset;Trusted_Connection=yes;TrustServerCertificate=yes" --target-database-write-mode Overwrite --options-file E:\Documents\git\TDM-Demos\rgsubset-options-bb.json
When I do that, I know see these row counts. Note I now have batting rows.
My player query won’t work, so I still need to declare another relationship with the dbo.teams table. That is shown below:
I can re-run the same command above, and then I see this set of rowcounts (original on left, subset on right).
There is teams data, and if I re-run my queries from the top, I can see stats now.
Now I have a dataset that I can perform development work with in terms of players, teams, and batting.
I can also add more relationships as needed, for example, I’ll add this section to include pitching, batting post, and fielding. Here’s my complete options file:
After re-running the subsetter, I have these row counts. Note there are rows in all the tables defined in the options file.
I can keep adding in more tables as needed to ensure the subsetter can walk down the data relationships I need in my database to produce a useable dev/test dataset that’s smaller than production.
TDM can help your devs build better software and with the subsetter, this can create lots of agility to ensure the data you need to accurately build this software is available.
Give TDM a try today from the repo and a trial, or contact one of our reps and get moving with help from our sales engineers.
Video Walkthrough
Check out a video of my demoing this below:
Posted inBlog|TaggedRedgate, subset, syndicated, TDM|Comments Off on Adding Manual Relationships Between Tables in the TDM Subsetter