My T-SQL contribution for this month is about using database analogies. Because it is something I have had to do a lot both personally and professionally over the years.
This month’s T-SQL Tuesday is hosted by Rob Volk. Rob has invited us all to talk about database analogies this month.
You can read more about the invite in detail by clicking on the T-SQL Tuesday logo above. In addition, you can read the Cambridge dictionary definition of an analogy here.
Database technologies analogies
In reality, I have used analogies a lot for database technologies over the years. Something a lot of people who have worked with me will vouch for.
For example, in the past I’ve said that Managed Instances is conceptually a bit like RDS. Because they both offer a SQL Server instance. In reality of course they are very different.
Another example is when I first started explaining Spark to people back when I was working with Hadoop more. I told them it was conceptually a bit like using In-Memory OLTP across many servers. Again, in reality Spark is a lot more complicated than that.
Interesting database issues analogies
However, I have to admit I have used a fair few to describe some interesting database issues over the years. For example, the ones below.
- That’s like putting the engine of a slow car into a sports car.
– When I found out a server with a large amount of RAM only had 32-bit version of Windows OS installed with no changes. I used actual car names here so I will let you come up with your own variants.
- It’s like using a sledgehammer to put a nail in.
– My description of using sp_msforeachdb and sp_msforeachtable together to update all the statistics in all the databases with fullscan.
- Sometimes it’s like spinning plates.
– Surely anybody who’s dealt with performance tuning has felt like this at times?
- It’s like a very unfunny comedy of errors.
-After a very bad backup issue there’s a reason I strongly advise people to test their backups. Like I mentioned in a previous post here.
- Like trying to drive when there’s no fuel in the tank.
– How I felt towards the end of working for a long time to fix point number 4.
- Closing the stable door after the horse has bolted.
– Trying to resolve an issue after it is too late.
- Building a well performing server is like building a high-performance sports car.
– Self-explanatory, from the old days where I use to build and install servers manually.
- Understanding indexes is a fine art to master like anything else that takes a lot of time.
– I think of lot of people can relate to this one.
Other technologies and ideas
However, using analogies like this can give people an initial idea about other technologies as well.
As part of my current assignment I am a Product Owner for a SQL team for a four-figure number of SQL Server instances.
Because I have spoken to stakeholders at various levels within the business I have to use analogies a lot. Of course, it depends on the audience.
In some meetings I could end up using analogies for some people and then going into technical details with others.
I get asked a lot about Azure DevOps at the moment. Often by people who use other services for things. Which means I at times I have to use analogies to give people an idea about certain services.
A couple of times people have pushed their dislike of certifications or training a bit too far. Personally, I always think we should strive to learn more. If they go too far I tell them that’s like saying they’d let an untrained heart surgeon work on them.
Well I hope you enjoyed reading my database analogies. As well as my analogies for other things.
Of course, I do realise some people will read some of these and straight away react that some things are different. However, they were the best way to explain things at the time.
I have to admit I do find myself using them a lot more these days to help explain things better. Maybe it’s because as your brain gets older it creates more interesting ones to help you remember things.
It gets more data just like a folder people use to store miscellaneous files in over time. On that final analogy I will finish this post.