247. Do Developers Need To Know About Databases?

Do software developers actually need to know about databases? Do they need to understand SQL or is knowing Entity Framework enough? These are the questions we will answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

Do developers need to know about databases? Do you need to know SQL to be a good developer? Let's talk about it in today's episode of Dev Questions.

SPEAKER_00 0:18

Welcome to the Dev Questions Podcast with Tim Corey.

SPEAKER_01 0:21

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about if developers need to know about the database. Being a developer means you need to know at least a little bit about a lot of things, including source control, CICD, multiple languages, the cloud, and more. For most of those areas, you can get by with knowing just enough. But what about your database? Should you know more? Now, normally my answer is it depends. And since I said the word need, I guess that's true here. However, the real answer is yes. Yes, you need to know about the database. But let's talk about why. Okay? It's important to understand, and let's just use SQL today, but it can be any database that you're using. So it's important to understand SQL well when you're using it, not just say, well, entity framework will handle that for me. All right. So here's why. Number one, applications exist to store and retrieve data. That's really the purpose behind applications. And you might say, well, no, no, no, not my application. Think about it. What's it doing? It's showing information, it's asking for information, it's storing information, it's manipulating information, it's displaying information again. Okay? That's what your application does. Now, there's a lot of complexities around that, but that's the whole purpose of your application. So your application really exists to process, handle, etc., that data from your database. So the two of those need to be able to talk well together. Because if your application is awesome and your database isn't, well, guess what? They're connected, they're linked. And so you're going to have a bad application. So it's important that the two work well together. Because the application exists to store and retrieve data. All right. Now, number two, performance is a key factor of your application's health, which makes sense, right? The faster your application runs, the more people can use it concurrently, the more you can scale up your application to more users. Application performance is important. Even in today's society where we have so much RAM and so much hard drive space and so much processor power that it feels like we don't need to think about these things. But the reality is you do, at least to an extent, especially if you're using your application at any scale. So with that performance being a key factor, well, again, your application is tied directly to your database. So if your database has poor performance, doesn't matter how good your application is, it's just not getting the data fast enough. And I've seen this a lot. I've seen a lot of applications where they're working on, oh, we should make sure we don't concatenate strings together, because if we do that more than five million times in a loop, then we'll have a two-second lag on our application. Well, sure, yeah, that's true. Um, but normally you're doing that for like five times or three times or one time. And so that performance difference is not even measurable compared to we wrote this select star from five tables with weird joins query that is going to bring back 100,000 rows, so we can display a number on the screen that indicates the overall total of our customer base. Well, you could probably do that better, right? And you're transmitting megabytes worth of information across from your database to your application server, and maybe even down to your client, and you're crunching all this data when you could have done it much more efficiently on the database server. So thinking through application performance, which is a key part of application health, means knowing how to make your database performant, not just your application. And since you're probably talking to your application, your database a lot in your application, well, you need to know how to make those calls efficient. You need to know how to measure the performance of those calls. Let me ask you a question. When is the last time you went to your database and said, what are the unhealthy calls? What are the calls that are really expensive? What are the calls we're doing a lot that may not be quite as expensive, but because we're doing a million times a day, that costs a majority of our server resources? How can we optimize those? When's the last time you did that? That's really important. And yet it's in the database side, not the application side. Now, number three, your company would probably fail if they lost all their data. Think of that through. Your application that displays data, that captures data, manipulates data, your application is using the data that's probably the lifeblood of your application, of your company. So I worked at an insurance company. Well, guess what? That database was all of our customers, all their insurance plans and policies, all the payment information, all that information. I worked at another company where it was a college, it was all the students, it was all their transcripts, all their courses they took, all the assignments they turned in, all this stuff. I worked at a number of different organizations where their data, the database, stores essentially the lifeblood of the company. And while the company may feel like, well, that's not what we do. Maybe we make widgets. And so data is not really important, right? Well, it's your customers, right? And your customers have orders, and those orders have to be fulfilled, and you need to know who is paid and who hasn't. And that's kind of critical. And if you don't have that one day, what happens? If your database goes away, what happens? Well, if you are writing application code and you're talking to the database, you are dealing with a very sensitive portion of your company's information. You are dealing with something that if you do it wrong, you could destroy your applic your company's application. You could destroy your company's entire livelihood. A simple example of this SQL injection. This is still a thing today, which is stunning and shocking. But taking data from the front end and packaging it up to do a query, and you don't do the right steps necessary to make sure that that data that you're given is filtered and cleaned up so that you don't accidentally allow malicious code from your form through to your database. This happens a lot where companies can have all their data lost, or even worse yet, corrupted. And this is the important thing data integrity. Because your form may capture data and it may not allow anything malicious, but maybe it doesn't do it quite right. Well, imagine if you're capturing information and you're updating and overriding information in the database, but it's not quite right. Well, that'll probably be something that gets past all your backups because you've been making changes, but it doesn't really, it's not noticeable. It's a smaller thing, but then you find out we can't depend on any of this data. At that point, it's too late, right? So data security, data integrity, these are important things to know. And it's not just an application thing. You have to understand your database as well. Otherwise, you could endanger your entire company. Number four, the choices you make up front can have a long-lasting impact on your application. I've been a consultant for a number of years, I'm not anymore, but I've spent a lot of time working with companies when things went wrong, right? When they call me in, typically it's Tim, can you help us? We've made some mistakes, we've got some problems. And often performance is a big issue, or data integrity is a big issue, or they find out they fail an audit because they have some serious issues going on and they need help. But one of the things I notice is that a lot of people don't necessarily live with the consequences of their own actions. They they build something, they think this is a great architecture, and they build something up at a company, and then they leave. And it works. Okay, it works through the first five years of the company. And so they may stay for five, 10 years, even, and then they leave the company, but their application stays there. And it continues to work until some point they have some problems. And then it's kind of too late. I've worked with a company recently where they're working through the implications of a poorly implemented entity framework application, where it's.NET framework, they can't upgrade it yet, they're working on it. But even so, the issue isn't.NET framework. The issue isn't they use entity framework. The issue is they poorly implemented it. They didn't understand their database well enough. So they said, well, but we know entity framework. Kind of. They actually didn't. They thought they did because it worked. And that's the scary bit, is it works. So what happened was they started down a path. And that path went this direction. It went, it went off to the left. But then they could have made a decision back here at the beginning to go slightly different. And if they had done that, they would be in a much better position than they are today because those paths diverge the farther down the road you go. And at some point, the distance from where they are to where they want to be is just too far. They've integrated things too tightly into the application to change how they do things now. And so what happens is the solution often, the cost-effective solution often is to throw more resources at it. And when you're working in the cloud, that gets expensive fast because the cloud charges you the more resources you use. Well, when your database is millions of people large, even though you're a small organization, and your database is massive, it's hard to back up, and it bogs your entire application down when you have 100, 200, 500 concurrent people using it, that's a problem. But the solution can't always be let's put more RAM in it, let's get a bigger CPU. Because at some point you run out of those. And in fact, they had run out of those. And so they actually took it to the cloud because the cloud has more resources than they can have in one physical server. But that's not the solution you want to get to. Okay, so you want to think about the long-term impact of your decisions up front. The database you choose is important. The way you architect your database is important. The decisions you make about how you access your data and how you put data back into your database is important. And if you only know half of the equation, the application side, then you're not going to make good enough decisions without luck. And that's not a great place to be. So just knowing your database a little bit or even having a passable knowledge is probably not good enough. You need to spend time to know your database well so you can make informed decisions about what your application is going to do and how it's going to work. Your application's health and even the level of success your company sees depends on how well you build and maintain that database. Spend the time necessary to get it right. All right. Thanks for listening. And as always, I am Tim Corey.

SPEAKER_00 13:08

Thank you for joining us for this episode of Dev Questions. When you're ready to learn to think and code like a professional developer, head over to IamtimCorey.com and enroll in a course.