This week I hosted T-SQL Tuesday. This monthly event suggests a topic for bloggers to write about. It’s been going on for many years, and you can find more details here. https://tsqltuesday.com/
For my specific post, you can find the summaries here.
I’ve spent 20+ years being asked questions about the DB. Some of them are simple to answer.
“Should you store images in your Relational DB?”
No….please stop doing this.
Hopefully that statement caused a few people heartburn.
Because I’m sure you can find a reason to do this. Nothing is universal in the DB world when it comes to what you can do with the database. We keep pushing the limits and putting more things into the database. “It depends” is a common, favorite answer because it really does depend. I have seen entire companies built around the DB, where the DB did way more work than application code and processes. All the logic lived in the DB. This had a lot of issues, but it did make a successful company. In business, it doesn’t matter if it’s a perfect system; it matters if it produces the results that work. Yes, sooner or later you'll have to pay back the debt you created, but for many companies “later” can be decades.
DB systems have become the one-size-fits-all mantra. Engineers don’t want to keep up with 200+ variations of databases; this means we are going to get the tough questions, and we are going to have to analyze the Risk vs Rewards of doing these things.
It is NEVER wrong to ask these questions. In fact, I welcome these sorts of debates. I had my entire DBA team focus on the question,
“What if we didn’t use a relational database for the production system?”
These questions and these discussions are critical for us to decide if the DB is doing the right things. The problem is, if we decide we are misusing the DB, does the Risk outweigh the cost of changing it?
When someone comes to you and asks the simple question,
“Can I add an index on these 3 columns?”
Perhaps the answer is simple:
“No problem, indexes don’t cost much”.
But what if? The table has 5 billion rows, 300 columns, and already has 25+ indexes. That changes the discussion a lot. You may risk the overall system by adding another index, but if the engineer tells you that adding this index lets you remove 3 more indexes from the table. Then your reward has gone up because you are improving the process.
These discussions happen constantly in the DB world. Below is a list of key items I ask for in these discussions.
“Ask: Is this a short-term change or a long-term change?”
“Ask: Do we have any load data to compare this to, something that shows the regular usage vs. what is being proposed. Always try to find some sort of data to help your decision”
“Ask: Why is this required? Do we have money attached to some deal? Do we have a request from thousands of customers? Did the CTO read an article about AI and needs it implemented now? (Not a good risk vs reward)”
“Ask: Is the process still needed? Perhaps you are simply fixing something no one uses anymore? “
“Ask: When is this needed by, or what is the timeline for this project? Defining time gives you an idea of the project's scope and what it might mean down the road.
These aren't everything you can ask; they're just simple guidelines. Notice none of my questions deal with cost or effort. These are discussions you need to have, but this VARIES greatly across companies and teams. You need to create those questions based on the company and the teams you work with. No ROI discussion is one-size-fits-all; what something costs a startup is very different from what it costs a large Fortune 500 company.
Risk vs. reward, or ROI, doesn't have a simple playbook. If you are a DBA in a company, you'll spend a lot of your time analyzing this, and the universal truth is that you have to make the best decision you can with the data you have. The more data and more experience you have, the better ROI you will produce.
Get out there and practice!