What is a Database Management System? The IT Director’s Podcast

Jay: What is going on? This is Jay and Michael, and we’re here on the Clear Winds IT Directors podcast. And look, Michael, we have an extraordinary guest today.

Michael: I would say this is a legend that we have with us here today.

Jay: Living legend right here, sitting to the left of me. For all of our listeners and viewers, we have the mighty Rick Goudeau, who is employee number two.

Michael: Numero dos.

Jay: That’s right… number two at Clear Winds Technologies.

Michael: Oh, yeah. So, hey, we’re a 25-year-old company. Rick, have you been doing this for 25 years? How—

Rick: Oh, no. I’ve been doing computers much longer than 25 years.

Michael: How long is much longer?

Rick: Let’s say about 50 years, or so. It was the late ’70s that I started working, but I took some classes in college, and even in high school I had a teacher that got kids on computers—

Jay: Wow…

Rick: —in 1971. And yes, I was in high school back then.

Jay: Okay. Rick, I dare say you’ve had some experience in this field.

Yes. I mean, look, for our listeners and viewers, this episode is phenomenal, because those of us who have been in technology a long time — Rick, right — we have a wealth of knowledge and life experiences, and now technology has changed so much.

Rick: Oh, absolutely.

Jay: And hey, it’s great to get to build and couple our experience with modern technology. So we’re going to talk about databases today — what is a database, what is database management, and just a lot of things about databases. Rick is our database specialist here at Clear Winds Technologies.

Michael: Mm-hmm. And with over 50 years of experience, I think Rick knows what he’s doing.

Jay: Yeah, I would say so. I would put him there.

Michael: Oh, yeah. And I want our audience to get to know a little more about you and your experience. So if you could say, “Hey, here are a couple quick fun facts about myself” — ’cause I know a couple, and I’ll drop them, but I want to hear you say them.

Rick: A couple quick fun facts. Let’s see. I got into computers during high school, and in college I actually took some database courses, so I got into databases in college and was just fascinated with that whole concept.

Michael: Mm-hmm.

Rick: I don’t know, drop me one of the fun facts.

Michael: One of the most interesting fun facts I’ve learned about Rick Goudeau is your Civil War reenactment.

Rick: Oh, yeah.

Michael: I don’t even know if you know this.

Jay: No, I do not, yeah.

Michael: So, okay.

Rick: Yes, I go out and wear wool in 90-degree weather for fun.

Jay: Wow. So you reenact the Civil War?

Rick: Yes. I primarily do Union, because Union’s easier to do — the uniforms are much more consistent. Confederate, you’ve got to figure out what unit you are, when they were equipped, where you were — it’s just a nightmare.

Jay: Man, that is such a cool fact. That’s a great experience. Where do you go to do that, Rick?

Rick: There are a few local events here in Alabama. There’s a lot in Tennessee and North Georgia, and in fact I just came back from one in May at Resaca, Georgia, which was one of the battles during the Atlanta campaign. I laugh and tell people that at night, we sit around the campfire and talk about our clothes.

Michael: That’s awesome.

Jay: That is so good. Well — hey, we’re going to get going and roll into what we’re talking about today. So, Rick, how long have database management systems been around?

Rick: Well, they started back in the ’60s with IMS, which was written by IBM — Integrated Management System. Fun fact: it was written to manage the bill of materials for the Apollo missions.

Jay: Oh, wow.

Rick: That’s what they used it for.

Michael: Okay, very cool.

Rick: And then IDMS came in the early ’70s — it used a different model. During the early ’70s, Edgar Codd had built up this whole new model, the relational model, and when I was in college everybody was talking about this new model of how we could build databases from tables, and that there would be a specialized language to interface with the databases for access, called SQL. Chris Date was also working with Codd to build that whole model. But everybody said, “It’s not practical yet.” It took until the mid-’80s before there were viable products on the market, things like DB2 by IBM, Oracle — sounds familiar, right? — SQL Server, but that was written by Sybase; Microsoft bought SQL Server and built the Windows implementation on it.

Jay: Oh wow, okay.

Rick: They were later. And then open source came with the open-source revolution in the ’90s — things like MySQL and Postgres. I always call it “Progress,” but it’s Postgres.

Jay: Yeah, I have to remember to put the T in there.

Michael: Yeah. So you’re going to have people listening — hey, they might be starting their journey, or they might be 40, 50 years into their journey. For those who are more on the front end, just explain what a database management system is. What is it, what does it do?

Rick: A database management system obviously manages your data — duh. But beyond that, it’s a way to structure your data and store it so you can keep it and retrieve it when you need it. When you start talking about database management systems, you’ll hear terms like ACID. Let’s see if I remember it: Atomicity — don’t ask me if I pronounced it correctly —

Michael: Sounds good to me.

Rick: — that means a transaction is a unit: either everything gets done or none of it gets done. So if the transaction fails, it can roll back all the pieces. Consistency means there are rules inside the data that make sure certain relationships and pieces of data exist together. Then I is for Isolation, which means if you’re making a change, I don’t see it until you finish it, and we don’t conflict with each other.

Jay: Yeah.

Rick: And D is for Durability, which means once you make your change, it doesn’t go away, period, until you explicitly make it go away — which is another change.

Jay: You know, that’s so interesting, Rick. Michael, just letting our listeners and viewers know — databases, relational tables, and database management systems haven’t changed a ton over the years, right?

Rick: No, that model that Codd came up with is still in use 40, 50 years later.

Jay: Yeah.

Rick: And it’s still the primary use. Now, the model calls for tables — it’s very highly structured. You can explicitly define columns within the tables and relationships between the tables, and it works really well for retrievals. Other things it doesn’t work as well for are things like what we’re doing now — video, audio, images. It’s been extended so you can store them in databases, but all the features around searching don’t really exist for those.

Jay: Yeah, and that’s what’s incredible to me — 40 years later, the database tools are structurally kind of the same. I can remember when I was first the director of technology, Michael — we had a RISC 6000 system, a Unix, old IBM mainframe. I was so nervous — I knew nothing about it — and I could not get to Windows fast enough to get off of it, because there was no one in Birmingham who even knew how to repair it if something happened. This was around 2000. It was old equipment — we’d gotten it in the ’80s, with the district I was with. But in 2003 we finally got rid of it. That thing ran for like 24 years.

Michael: Wow.

Jay: Solid — just maybe some drive failures here and there. Pretty interesting that relational databases hadn’t even changed over that span.

Michael: Well, hey, what’s the phrase? If it ain’t broke, don’t fix it.

Jay: Yeah.

Rick: I have SQL scripts and stuff that I wrote back around 1990, and I still use them today.

Jay: Yeah.

Rick: Because the structures are still there.

Jay: Still there, yeah. So what do databases do for businesses, Rick? At a high level, how do database management tools and databases impact businesses in their day-to-day?

Rick: Like I said, it’s your central repository for the data of your systems. You need it so you can come back and use the data later. You need it for regulatory purposes, to run your applications, to run AI. Where do you think AI gets its data from?

Jay: Yes.

Rick: A database management system underneath that architecture.

Jay: That’s great, Michael. I’m glad you brought up AI.

Michael: Well, yeah, definitely. And I think we don’t always hear these phrases, and this is very much a field that’s critical, but you don’t realize how it underlies so many things happening today.

Jay: Yeah. And hey, look, I use AI daily, Rick, in my role. There’s one of me and 12 account reps, so I use these tools to automate and repeat tasks. But hey, that information is stored somewhere.

Rick: Yeah, that’s right. And it’s in a database — that’s where it’s pulling from. A lot of the information you pull from is a database. For example, what we use to manage our infrastructure and tickets has a database under it.

Jay: Mm-hmm.

Rick: If that data — that’s where it’s all stored — you can extract data from it.

Jay: Yes, mm-hmm. So what are some items needed to support database management systems?

Rick: Well, first of all, a database management system is kind of a generalized product — it touches a lot of things, and a lot of things touch it. You’ve got components like server management, because it’s like a mini OS. You’ve got items like caching, accessing hardware, accessing the network — so there’s some networking in there. It has its own security — you have users in the database with access rules that let them get to various data, so one department may have data that another department may not be allowed to see, or other companies, if you have multiple companies or operating units. Then there’s SysOps, because a database has an exclusive logging attribute — it tracks all the changes so it can recover from them. That has to be integrated with your backup software; the database has to be handled so the backup software works with it and not against it — and I’ve seen both happen.

Jay: Oh, yeah.

Rick: We can discuss that. And finally, there are applications — that’s the main use, to interface with SQL. SQL is a declarative language — you illustrate what tables, what columns, what filters you want to put on your data, and the optimizer, which is an early form of AI —

Michael: Hold on, go deeper into that. How so?

Rick: The optimizer takes your statement —

Michael: Mm-hmm.

Rick: — and it’s got the structure of the database in a data dictionary. It has statistics against the database, and it uses all of that to build access paths for how it wants to retrieve data from those tables. You don’t build that — you can kind of control it by giving it good prompts, but you don’t build it. It builds the access path for you.

Jay: Yeah, that’s interesting, Rick — I use a lot of these tools now, Michael. And hey, we’ve built some applications at Clear Winds. Rick is our — hey, I’ve been on some sites where they had old Access databases still running, and I was shocked people still had that.

Michael: Mm-hmm.

Jay: And I remember our VP of engineering said, “Oh, we’ll get Rick on that — he’ll be able to move that over for you.”

Michael: Oh, yeah.

Michael: Oh man, I’ve seen several of those conversations.

Jay: Yeah. Well — you’ve got some businesses that have run on the same systems for 30, 40 years and nobody can touch it, and that’s when it’s like, “Hey, call Rick.”

Michael: Yeah, call Rick.

Jay: And that’s pretty interesting.

Rick: And I’ll point out, one of the things I remember from back in the ’90s — one of the first things I do when I look at an Access database or Access system… Access is also a programming language and a database. The first thing I do is not get rid of the database — we don’t want to use that; instead, I substitute SQL Server for Access, and let Access go access SQL Server. It works perfectly, and that was 30 years ago.

Jay: Rick, let me — I’m going to date myself, Michael. This is news to all you guys. Y’all learn stories about us all the time on these podcasts. So one of my first roles, Rick — in my previous position, I was managing servers, and this was in the late ’90s, early 2000s. We didn’t have a ticketing system — I mean, the ticketing systems now are a dime a dozen, right, web-based ticketing systems —

Michael: How’d you manage it?

Jay: Yeah, so, hey, we had Access, and I worked in the data center. We had programmers, different roles, so I created an Access database — I wrote a ticketing system. We called it the “call tracking mechanism” for the place I used to work at. And hey, we started using that, and that’s how we tracked all of our tickets. That thing grew, and I didn’t understand the growth or the relationships and how it would grow. But this was 20-something years ago; I wrote that in Access. Hey, we used that thing for about 10 years, Rick.

Jay: And then they migrated to web-based products, like we have School Manager and different things like that. But when you said that, it was interesting, ’cause I was teaching myself on the fly, and man, it was a beautiful tool. We’d have people call in needing help — we didn’t have a way to track the tickets and issues, Rick.

Rick: Oh, yeah.

Jay: I know…

Rick: Because once you had it in a database, you could build reports against it.

Jay: Then we could build reports — we started doing reports by location, servers, users —

Rick: Mm-hmm.

Jay: — it was incredible. I was way ahead of —

Rick: Yep.

Jay: — what I knew at the time. But if I fast-forward 25 years, like you’re talking about with AI, you can create that in 45 seconds. It took me days to do that, Rick, and weeks to work through bugs and upload locations and stuff. So it’s very interesting you bring that up.

Rick: Just remember, AI doesn’t always give you the right answers. For real. So you’ve got to know the underlying things so you can catch that.

Jay: Oh, 100%.

Rick: Because I’ve worked on some AI systems, and it’s like, “Yeah, we’ve got to go fix this and this.”

Jay: Yeah.

Rick: But that’s part of it. Fun fact for us: Clear Winds’ original — not ticketing, but timekeeping system — was a homegrown system built on SQL Server.

Jay: Okay.

Rick: It used SQL Server — so it was in a database.

Jay: Yeah, a lot of people did that.

Rick: Because why did it use a database? I made sure it did.

Michael: Well, I was just even — man, I’ve known you for a while, but let’s talk about skill set. What does it look like, and how are you wired? Two questions: one, what’s the skill set it takes to manage this, and two, what are you most passionate about with this? Because, man, if you’ve been at it for 50 years, you’ve got something that drives you, and I want to dig into that.

Rick: Okay, we’ll do the skill set first. Like I said, I outlined a bunch of stuff that it touches. One of the skill sets is server management — the same type of skills a systems engineer has.

Michael: Mm-hmm.

Rick: Because it’s a complex piece of software, with all these pieces of caching and everything, you’ve got to be able to manage it like an OS. You need disks, SANs, and hardware knowledge. And when you patch it, it’s a little more complicated than being a systems engineer, because you don’t just patch software — you also have to patch the database and run scripts, since an upgrade may force database changes that have to be kept in sync. So you’ve got all those pieces to handle, just like systems engineering. You’ve got SysOps, because — like I mentioned with backups — you’ve got to make sure your backups are there and whether they’re good. It’s coordinated, because databases have what they call a logging chain: every time you update a database, it logs the changes so it can roll forward to a specific point. I’ve literally had times where systems had issues, and I could roll forward — they’d say, “Well, when do you want me to roll forward to?” “Oh, 3:13:30.” I can do that.

Michael: Mm-hmm.

Rick: As long as the backup software cooperates with me and doesn’t break that chain. So you’ve got that piece. You’ve got the networking piece too, because people might say, “I can’t get to the database.” Okay, why? You have to know enough to troubleshoot and figure out — ports have to be opened, DNS could be messed up, you don’t know — but you’ve got to be able to eliminate those as possibilities.

Jay: Mm.

Rick: Then there’s the security component. I’m afraid a lot of people treat the security component as, “why worry?” — because you have users with access to the database, and those users also have access to tables, and you don’t know how many times I’ve seen a company using the schema owner — in other words, the account that owns all the tables — as the application owner, the application user, or worse, using the system administrator account for the application, which means there’s no security inside the database at all. Here’s a good example: I had a system where somebody created an Access database using the system owner account. Access said, in effect, “Oh, system owner — here, let me update this table and change this definition.” It broke the entire application. We had to recover and restore the application to get that table back. Why? Because he used the wrong schema. If he’d used a different schema, it would have said, “No, you don’t have permission to do that.” He didn’t mean to do it — the system just let him.

Jay: Yeah.

Michael: Compare this to how AI works today.

Rick: Well, take AI — if you don’t review it, you could break your system the same way. It could generate code that eliminates key data, as long as you have permissions to do it. You don’t even need AI for that — I still remember in Unix land, I was trying to delete a directory, and in the Unix command — I won’t get into the specifics — it’s “rm -rf,” delete the directory and everything below it. And it kept telling me, “You don’t have permissions to do that.” I was like, “What? Why can’t I do that?”

Rick: Then I realized I was in the /bin directory — the root level of the system software — and I was trying to delete everything. It wouldn’t let me, and that’s when I said, “Ooh, that’s why I don’t want to use the system administrator account except when I really need to.”

Jay: Yeah.

Rick: And that’s what AI can do if you’re not careful and don’t review it.

Michael: Okay.

Jay: Well, Rick, I think database specialists and administrators in your role have to be so multifaceted, right? When you started, you knew programming and structure, but you have to know a lot of technologies —

Rick: Yeah.

Jay: — to be a database specialist, because you’re talking about networking, security, storage, switching —

Rick: You don’t have to be experienced in it — I couldn’t build a routing table to save my life. You just have to know how it works, have an idea about it, and know how to troubleshoot or at least handle it. And I didn’t even get into application development, which is another key skill set — probably the other wing of being a DBA, because that’s data analysis. What tables do we have out here? Nowadays we use a lot of applications, and guess what — each one has its own database. Take something like ERPs, which have purchase orders, receipts, AR (accounts receivable), and CRMs, which have customer data. There’s overlapping data — like your customers may be in both systems. So which system is the true source? You may have to build interfaces from one system to another so you can synchronize the data. That’s data analysis too — because what happens when you have a contact in your CRM and the contact’s not in your AR system? Which one do you use?

Jay: Yeah.

Rick: And personally, how many times have you been at a company where you have to enter the same information multiple times?

Jay: Yeah, mm-hmm.

Rick: And I’m like, “Oh yeah, I’m feeding this — here I’m feeding their CRM, here I’m feeding their billing system, here I’m feeding something else.” I can do that and know where things go.

Michael: So back to that question — what would you say you’re most passionate about in this field? Because you’ve stayed in it for 50 years and made progress for 50 years. What’s kept you plugging away?

Rick: I think for me it’s been a lot of the data design — I like figuring out SQL, and I didn’t even get into how you use SQL to build SQL, or how you analyze when SQL is going wrong and what you need to do. There are just so many pieces to it. I think SQL and data analysis are the more interesting pieces for me.

Michael: Okay.

Rick: Like I said, sitting there figuring out, “Oh yeah, this is which system I’m putting data into” when I’m working with a company.

Michael: Yeah. I want to hear if you could give some advice to people at different stages of their careers. So for somebody who’s just thinking about going into this field, what would you tell them?

Rick: Some of the other soft skill sets — we’ve talked technical the whole time, so let me think about some of the things that have served me well. One thing: in college I got a business degree, so when clients talk about accounts receivable, balance sheets, income statements, I know what the business guys are talking about. I know what a PO should generally look like, and that’s really served me well. Do I think you need an MBA? No. But taking some business courses helps, and I’d advise IT managers to let their people take some business courses as part of their training, even though it’s not part of their job requirements — especially if they’re in application development.

Michael: Yeah.

Rick: Let them go learn some things about the business side.

Michael: Yeah, I love it. I’m a firm believer in knowing, hey, here’s our organization, here are the different components and pieces, here’s where my department fits into the big picture, here’s how we relate to and help all the other departments push our mission along. So taking that well-rounded approach — I can appreciate that. That’s wisdom.

Jay: I love it. Rick, you’ve talked about some amazing things on this episode. I’ve learned a lot, and I’ve enjoyed listening to you, with your depth and wealth of knowledge, very vast in the field, because you’ve been in the field for many years, right? Over decades, so you’ve gotten to see different technologies — but you also talked about the business side and understanding it. That’s why Rick is so great at what he does — not only do you understand the technical side, Rick, you understand the business, how operations work, and how databases impact business — the ROI for companies and their workflows. I think this episode is going to be amazing for our listeners and viewers, and Rick, we can’t thank you enough for being on the show today. I think you’ve been a phenomenal guest, and I can’t wait to spend more time with you.

Rick: Yeah. And I’m trying to think, while you were finishing up, what other things helped me. I love taking notes, and I’m a big believer in checklists, so you document what you do at every step. Because guess what — you’re going to have to redo it again sometime.

Michael: Oh, absolutely. Mm-hmm.

Rick: And frequently, when I do maintenance, I do it in test, maybe in user acceptance, and then in production. And if you have a complex application structure, you may want all three. I’ve seen a lot of companies that only have production, and I’m like, “Okay, let’s find out what happens when we try to do this. Let’s run this update and see what breaks.” And then you’re always asked how long it’ll take. Until I’ve done it, I don’t know. It’ll take as long as it takes.

Jay: Yeah, I’m a big note-taker on that front too.

Rick: That’s being detailed.

Jay: That’s why you’re great at what you do, you know?

Rick: Mm-hmm. Yeah, and sometimes those notes come back to help you. I remember I got asked to do something a few weeks ago, and I thought, “Didn’t we do this before?” So I searched through my notes and found it —

Michael: Your own personal database —

Rick: — from my own notes. In 2013 I did the exact same thing, and I thought, “Oh yeah,” reviewed it, and thought, “Yeah, this’ll work.” So I could take that and go from there.

Jay: Wow, that is sick.

Rick: So 13 years later, I saved myself like half a day or a day just by saving those notes.

Jay: That’s awesome.

Rick: That was in a database somewhere.

Jay: Yeah. And that’s what I think — Rick, that’s where — Michael, our listeners and viewers, especially our younger generation coming up in college and getting into the technology or marketing field, whatever — a lot of people fail to realize that all these applications, all these tools we have, there’s a database in the background driving all of it. So I think database management is such an amazing field, and really one of the fastest-growing fields — being a DBA, programmer, or developer — in today’s current climate with AI and all these tools, because that data has to be stored somewhere. So, look, we’re going to end this episode. I think we could have Rick back on to talk about a lot of other stuff.

Michael: Definitely. Oh, I know more fun facts — we can get into those later.

Jay: Yeah, we can get into those later. But look, hey, Rick, thank you so much for being on. This is Jay and Michael on the IT Directors podcast, and we are out.