Database Concepts | CompTIA IT Fundamentals+ (FC0-U61) | Free Test Prep Course from ITProTV

Database Concepts | CompTIA IT Fundamentals+ (FC0-U61) | Free Test Prep Course from ITProTV

Hello, and welcome to ITPro.TV. You’re watching the CompTIA IT
Fundamentals for Exam FCO-U61. I’m your host, Ronnie Wong, and today, we’re gonna dive into
the realm of database concepts. And here to help us understand that of
course is gonna be Mr. Don Pezet, himself. Don, welcome to the show. How are you doing? Thanks for having me back Ronnie. And one of the purposes of the IT
Fundamentals course is to expose the viewers to several different areas of IT. [LAUGH] And let you see the different types of work that happens in
your average IT department. Well, one area that has grown
exponentially over the last decade, really the last two decades,
is the area of database administration. Databases have become
mission critical to many, many companies, have just become a key
component of any kind of business logic or function and
are just really incredibly important. So sadly it’s kind of disturbing to see where databases are kind
of mysterious to people. Where a lot of people don’t touch them,
know they’re there, know what they are and understand what they do. So in the next couple of episodes, what
we’re gonna do is we’re gonna focus on databases and show exactly what they are,
how they work, how they do what they do. In the hopes that it piques your interest
and encourages you to continue going on and learning more about
database administration. But in this first episode,
I wanted to keep it easy and start with database concepts. If you’ve never worked with a database
before, if you don’t exactly know what a database is, let’s just start there and
figure out what is a database. How does it work? How does it do what it does? And then in the next couple of episodes, we’ll get a little more into working
with them and seeing what they do. But right now, I just wanna set up
where that base understanding is. That’s what we’ve got coming
up right here in this episode. Now, Don, I’ve talked to several people before, and they’ve told me they
know exactly what a database is and when they show me what one is,
they just show me an Excel spreadsheet. Is that what we’re talking about when we
talk about what a database really is? Sort of, yeah, it’s a type of database. The example I use, and this is not so good for younger people,
is like an encyclopedia, right? If you’re a little older, like for me, we had a paper encyclopedias as a kid. [LAUGH] A big set of volumes A through Z and when I wanted to figure something out,
I could go here and pull up and I could see it,
that encyclopedia set was a database. It was a collection of data arranged in
a way where I could find what I wanted. If I wanted to look up the Queen
of England, I can go and grab the Q volume and
flip to queen and probably find it. Or I’d go and grab the E volume and find England and
it might tell me I’m in the wrong spot. And have to go to the U volume for
United Kingdom or something like that, but it would point me
in the right direction. I would get the data that I wanted. I would get my answer. Today, we don’t see databases
as a giant collection of books because books weren’t very efficient. It took a while for me to go in there and
find that stuff, right? To say, I’m gonna go to that Q volume that then sent me to the U volume
that then sent me to wherever it was. It took me a lot of time to find
the information that I wanted. And the data got out of date pretty quick. Encyclopedias were expensive. I didn’t buy one every single year,
so you’d have a set. I remember the set I was using
as a kid was 20 years old and as long as I was dealing with history, it
was fine, but if I wanted current events, I was out of luck. Well, today,
we have things like Wikipedia, right? Wikipedia is a database. It’s actually a massive one. Let me bring up,
we’re gonna bring up Wikipedia here. So if I go to Wikipedia and I wanna
learn something like Queen of England, right, I’m just coming in here and
I’m typing Queen of England, right? So I’m gonna type that one in and
I’m gonna search for it. Now, I didn’t have to go and find a volume, but somebody did in the
background, the computer system did it. It has this collection of data, and it
went in and it found Queen of England and it said, hey, guess what, Don? There’s been more than one Queen, so this is not necessarily the best
search I could have done. And it’s doing disambiguation and
telling me, actually, I’m probably meant to look for
some of these other things and sure enough it’s saying, hey,
you could go and look up United Kingdom. Or you could go and look up specific
queens if I wanted to find them and look that up and get at it, right? So maybe I wanted just the general role or
maybe I wanted somebody specific, like Elizabeth II. And I can click on that, and
I start to get that information, and there it is, right? This data is coming from a database, and the database is massive,
packed full of a ton of information. I need to be able to get
at that information. And that’s what a database is all about. Now, Ronnie said, what about Excel,
right, what about Microsoft Excel? If I fire up a spreadsheet and I put some
data in there, isn’t that a database? Yes, yes, it is, right? The difference is how much
data you can fit in it. An Excel spreadsheet, that’s designed
really just to support one person, right? One person at a time, gets in there and
works with it, gets their data out. It doesn’t scale all that well, right? But a database can. How many people are on
Wikipedia right now? I don’t know, but I’m sure it’s in
the tens of thousands right now. Millions of people use it every
single year and it does just fine. When I did that search,
was there a big delay? Did I have to wait while it processed and
calculated. No, it already knew to
churn out that information. Now, I don’t know how many
people are searching for the Queen of England right now. Probably not that many, but
it didn’t even bat an eye. It just immediately turned up those
results and got them out to me. So that’s the big thing that databases do. Now, I used Wikipedia as an example
which is not really, I don’t know, the most business useful type of thing,
Wikipedia, non-verifiable information. But there are a lot of databases out there
that have critical data in there that’s really useful for making business
decisions or powering businesses. A better example might be,
right? If I go to,
I’m gonna go to their website, right? And first off,
it’s displaying a bunch of products, mostly a bunch of junk that I could buy. So here’s junk I could buy, right? But I wanna buy something specific. I wanna buy The X-Files on DVD. So I can come in here and
type X-Files DVD, right? And so it’s gonna search. And it searches their database. They have a database of all of the
products they sell with the prices that are available and whether they have Prime
shipping, and all that’s in the database. And it gets searched and
it shows me the products and I come in and I can find the complete series and
movie collection. This is like everything
that I could possibly want, all right here in this product, right? And it finds it quickly. It displays it. Now, I can buy it. This is a business being
driven by this database. There’s plenty of high
level examples like that. The US Census, where they collect information about all
of the citizens here in the United States, so they can figure out how to portion
out tax money and other things. Who knows what they do with
all the data these days. But they collect all that information, that’s stored in a database that
we can then act on it, right? Databases are key pieces to
making good business decisions. If you make a decision, the quality of your decision depends
on the information you have. If you don’t have a lot of information, the odds are you’re
gonna make a bad choice. But if you have a ton of information, the
odds are you going to make a good choice. Databases give us that information, well, even a database is only as good
as the data you put into it. So assuming we put complete information
in there, it works really well. So for example, imagine Amazon, they have all of their products
listed in this database. But let’s say somebody gets a,
I don’t know, a jar of peanut butter, And they forget to put it in the database. They stick it on the shelf in Amazon,
but they never put it in the database. Well, nobody is going to find it. They’ll come in and they’ll search for
peanut butter or whatever. See this where I go off script and
I do a search, and something bad comes up. [LAUGH] Hopefully peanut butter is
a pretty safe thing to search for, so you search for it. And I find all these other
ones that are in the database. But this one jar they have
they forgot to put in there. Well, it’s just gonna sit on the shelf. And it’s not gonna get sold. And eventually it’s gonna go bad and
it’s gonna get thrown out, right? A database is not perfect,
it’s not a wizard. It just is as good as
the data we put into it. And once the data is there,
we can then make good decisions. That’s really what
databases are all about. And that’s really what’s powering
things is that we’re creating records, information, collections of data. And we’re storing it right
here in that database. And the database might be small. It might fit on one computer, right,
like an Excel spreadsheet does. Or the database might be massive,
Wikipedia. Wikipedia has a massive data base that is
spread across hundreds of servers to be able to handle that large
amounts of storage and data, because they have not just articles but
pictures and things. I mean it takes a lot of storage
to store a bright pink like that. So it takes a lot of effort for that. And that is part of what databases do, so
it’s really an impressive technology that is incredibly powerful. Now, Don the idea of you showing us all
of this information helps us out, because we know that we can go and
use these things on a daily basis. But that means if someone
behind the scenes has to get the database information together, right? Absolutely, yep. So there’s data input. There’s a couple different
operations we do with the database. We’ve got to put data into it,
that’s input. Then we get data out of it. That’s output, right? So you can’t get data out unless
the data has already been put in in the first place. And these two things are happening
constantly over and over, and over again. Well, I guess there are some
examples where it only happens once. For example, that census data I mentioned. That in the year 2010, they did a census. They collected all the data on the cities
and they put it in the database. Is that gonna change in 2011,
2012, here we are in 2018, is the data from 2010 gonna change? Not likely, so the input happened once. They input all that data from 2010,
but on the output side I might ask questions about 2010 over and
over again for the next 200 years. We might be checking like,
what was the gender division ratio or the racial ratios, and things like that
to find out which minorities are growing into majorities, which majorities and
shrinking into minorities, and so on. And figuring out where
different people are living, different economic backgrounds. Those are questions we will ask for
hundreds of years, right? And so, the output is happening way,
way more. Amazon, same way. Amazon is only adding so many products
to their database any given day, but people are ordering millions
of things on a regular basis, they generate an insane amount of revenue. So those are standard database operations. Now when we’re working with the database,
we don’t see a pretty webpage. We don’t see a shopping cart. We see the raw data,
which is very different. Let me show you an example of that. I’ve got a database pulled up. So this database server here that I’m
using is called Microsoft Sequel Server. There’s a number of database
products that are out there. Oracle has a database
product that is very popular, there is MySQL, MariaDB, PostgreSQL. There’s a number of different
data-based servers that are out there. Well, almost all of them function
the same way and use the same language. A language called SQL or
the standard query language, is a language we use to talk to the
database service to get information out. And we’re gonna see SQL
in another episode. But when I go in here, the database structures are pretty
much going to be the same across all the various products that I just
described, is that you have a database. Here I have a database called
adventure works 2016, all right? And inside of that database I have tables. And what tables are,
are collections of data. I have data that gets input,
that gets put into this system. And as I look in here, I can find
things like employee records and so on. So this company, I have a fictitious
company here that’s called Adventure Works and they have employees. And so, their data is being stored right
here in this human resources.employee table. And when a new employee gets hired,
they need to get added to this table. If you watched our episode on business and
productivity applications, you saw Microsoft Excel. And in Excel you had a table, right? Basically, a grid of data. Well, in a database you
have the same thing. If I were to edit this table,
when I pull up the table itself, here I’ll just edit the top 200 rows. When I pull it up, I’m gonna see a similar
grid to what we would see in Excel, all right? And as I look at that grid,
I can see that I’ve got column names. BusinessEntityID, LoginID,
OrganizationName, JobTitle, and so on. And the data is all just
stored right here in cells. And so, I could come in and
I could edit some of this, I could edit it directly right? So maybe I’ve got an employee
here who has a title, this is the Vice President of Engineering. And they get a promotion and I say, all
right, they’re not the Vice President of Engineering anymore, or maybe they’re
the Senior Vice President of Engineering. So we can come in and edit that record and change the value, if I can type it,
that’s the hardest part. And now, they’re
the Senior Vice President of Engineering. And if I were to query
against this database, I’m now gonna see that new
title attached to that person. We can jump in, modify that stuff,
and get it put in. Somebody has to add these records. And if you’re just adding them onesie,
twosie, like you would in Excel, you just type them in,
it’s all manual data entry, right? But databases are designed to handle
millions, billions of rows, right? Huge amounts of data. And when you do that, you’re not
normally directly entering data in. It’s normally programmatic. We have software that’s dumping
the data in for us, and that might be getting data entered in. It might be exporting the data,
backing it up, right? There’s different things that
you can do all programmatically. So when we look at the information here,
it’s usually information overload. It’s way more data than what we want. So working with the database, what we’ll normally do is
write what are called queries. And a query is question, where we ask
the database for something very specific. And we say, look, I know you have
a ton of data, that’s great. But all I really need is this one little
thing, can you please give it to me? And the server can then sift
through all of this data and give us what we want, right? A lot of people refer to these as reports. Think about it, a report is really just a
summary of some other kind of information that’s too complex to look at, right? If I wanna know what’s on television
right now, if I were to look at the programming schedules for every TV
station out there, it’s a nightmare. But if I just pull up the little TV Guide,
and I can see what’s on right now, this one hour, what’s on the various
channels that I have, that’s a report. It’s giving me a subset of data
that is far easier to handle. I don’t need the last 10 years worth
of TV schedule, I just need this hour, what’s on right now? And that’s how these databases work. So for example, [COUGH] let me show you, I
have a query that I wrote before the show which I thought I had sitting
around here but maybe I don’t. So let me just open up this query here. Here, employ hire dates. So I wrote a query before this show and
this is what a query looks like. And again, we’re gonna talk
more about queries later on. But what I’m doing is I’m telling
the database, I want a few things. I don’t want everything the database has. I want the first name, last name,
job title, and hired date of my employees. Can you please just give me that? Give me that data, just their name,
their title, and when they were hired. And if you can give me that information
it would really make my life easier. And when we run that query, you’re
sending that question to the server. And the server gets it and says okay,
I will give you what you’re asking for. And as I look down here I can see a nice
little table with the first name, last name, job title, and
hire date of every employee. And that really makes life easier, this
report, this data that I’m exporting here. That’s exactly what I wanted, I’ve got
that information and now I have it, right. And I can use it, and I might use
this versus using the actual data in the database,
cuz this is represented the way I want. And the cool part about these
questions is you can rephrase them different ways, right. When I look at this, what is it sorted by? It’s actually not sorted by anything,
is it, it looked kind of random, I figured it would sort on one column. Usually databases sort on one column or
another, this one doesn’t appear to
have sorted on anything. Which means it’s sorted based
on the date they were entered. So, Ken Sanchez was the first person we
entered in the database which makes sense cuz he’s the chief executive officer,
he was probably employee number on. And then we’ve got the senior vice
president of engineering, Terri Duffy, and then it goes down line. So this is just the order of entry. Well, maybe that’s not what I want,
maybe I want it based on their hire date. I wanna know which,
actually if I look at the hire date, Ken Sanchez was added after some of the
others, I don’t know what this sorted by, right. [LAUGH] So, we can tell the database when we ask it to
give us data, we can say, you know what, could you please sort this, sort it
by last name or sorted by hire date. I wanna know who actually was hired first. So I can just come in and
I can say, whoops, I can try and type ORDER BY and then what it
is I do want to order them by. So maybe it is HireDate,
and I can punch that in. And now when I rerun this query, I should
see everything sorted by that hire date. So I’m gonna rerun the query and
Ken Sanchez is not first in the list any more because
he wasn’t the first person hired. In fact, way back in 2006,
it looks like we hired a production technician named Guy Gilbert, manly name. [LAUGH] So Guy Gilbert came on in 2006, he was the first employee. Kevin Brown came next with marketing
because we have a product, we need to market it, right? So I guess that makes sense, and then they go through and
they start to add more people. I could easily change that and say,
you know I didn’t actually want HireDate, instead let’s sort this one by LastName. And we do LastName, rerun that query, and this time it’s
gonna be reorganized the way we want it. And Syed Abbas is now the first one,
even though he was hired in 2013, his last name starts with Ab and
so he comes first, right. So this is the power of a database,
you have a massive collection of data. And you can just sit there and
ask it questions, all sorts of different questions. And you can generate all sorts of
information based on the results of those questions and then you can make
intelligent business decisions based on all of those. Now Don everything that you’re showing here is neat and is amazing, but I still don’t see why it’s really that
different from an Excel spreadsheet. So why not continue to use something
just like an Excel spreadsheet? All right so we could, right, we could use Excel, right? It has a table,
you can put your information in there. The thing about Excel is it
just doesn’t scale very well. Excel has a maximum of 65,000,
which admittedly is a lot of columns, you’re rarely gonna need that many. [LAUGH] But it also has a limit of about a million rows. When we’re dealing with databases
like this, we could have billions or even trillions of rows. You could have huge amounts of data and
databases are designed to handle it. But the key difference, the main difference is how many
people can be in the system at once. Excel’s expecting one person to
access a spreadsheet at a time. And the bigger that spreadsheet is,
the longer any kind of reporting is gonna take to generate on it because it’s having
to generate those results in real time. Databases on the other
hand are designed for tons of people to be in them at one time. And it doesn’t matter how big
your data gets, that all these people getting in there will still be able
to get results really, really quickly. And the reason is that the database
is expecting you to run queries more than once. Excel isn’t, Excel expects you to run
a report or whatever one time and so it’s doing the work over and
over again every time you run that report. In a database though, you have what’s
called a query execution plan, and let me just bring this up. And this is something, hopefully
most of you never have to deal with. [LAUGH] But when I ran this query, a lot of work actually had to happen in
the background, we didn’t see that work. And if I take a look at this it can
come in and show me what that work was. So let me bring that up here so
we can see it, and if I can stretch this window just a little
bit, whatever I can’t get my mouse on it. Basically you see this
little chart right here, and this is all that happened
in the background. It had to do some clustered index scans. It had to take the results from those
scans, do a join, and loop them together. And once it had them all joined, then it
had to sort them, cuz I asked it to sort, before it gave me the results. All of this work had to be done. Well the database server figured out the
best way to do it to get the results as quickly as possible. And you saw it ran really quick,
in fact it tells me on here, somewhere down here at the bottom,
my head’s on top of it. But it tells me that query ran
in less than one second, and that’s actually tenths of a second. And then we’ve got 290 rows, I got 290
results back in less than a second, it was able to process that really,
really quickly. This is not just being run for me but
now the server saves that data. And it says that if somebody
else runs this same report, I already know how to do it. I might even still have the results in RAM
and I can just give them results with out running the query and
that makes this far more efficient. If Amazon was having to re-parse their
entire product library every time somebody ran a search,
it would take forever. Their costs would be through the roof for
the hardware to support that. But because the searches
have already been done and they’re already cached you
get the results way faster. So performance and scalability,
that’s what databases bring. You can do a lot with Excel, right? I could re-create this exact
stuff right here in Excel, and it would work fine if it was just me. But when you talk about scalability,
supporting an entire company, supporting your customers. Those flat files, those things like
CSBs and Excel spreadsheets and other workbooks, they’re not designed for
that, they don’t scale like that. Even more advanced applications like
Microsoft Project and QuickBooks, where those are effectively databases,
they’re really only designed for a handful of people to be in them,
not tens of thousands of people. That’s what databases do and
that’s what sets them apart. And Don, I think another distinguishing feature
of a database that helps us compare to an Excel file is that we can query from
multiple tables at one time as well. That the ability to not just query one
Excel spreadsheet and then look for another one and figure, it out it allows
us to connect those two together and be able to run that too. Now Don, even though we talked about us
and it did help us to understand that a little bit more, are there different
types of databases that are out there? Not just something like
a Microsoft SQL here? There are, and databases kinda fall into
three different categories. There’s structured databases,
semi-structured databases and unstructured databases. [LAUGH] Right, whatever, what I’m showing you here is what’s
called a structured database. A lot of people refer to it
as a relational database, the data is all arranged in a certain way. I have a lot of tables over here, all of these tables would be like
separate Excel worksheets, right? Except the difference is that each
table relates to another table somehow. Now let me show you a graphic I
whipped up before the show to give you an example of that. So here I have a table for my orders,
I’m a company, I sell something. People place an order with me,
so I have an order. And an order contains an order_id. And then it’s got to contain
who placed the order, right? So maybe there’s a contact information,
the product that was being purchased, the promo if it had a discount code,
that kind of stuff. That’s all being tracked
based on the order. Well, I also have customers. The customers, I might call them contacts,
but they have first name, last name, phone, email. I have my products that have names,
descriptions, they have a price or a cost. I have my promo codes,
if I have discount coupons, what’s the amount of the discount, right? These are all things that I have, but
they’re all related to each other. When I place an order,
an order is being placed by a contact, somebody’s buying something. And they’re buying a product,
that’s the something. And they might be using a promo code,
they might be getting a discount. All of this is related together
in a structured database. We have a very well enforced structure
that defines what data goes in the table. And then we have relationships that
define how it’s tied together. You can have a semi structured database
where there is a structure but it’s not really enforced. And when we talk about enforce, databases have what’s called a schema
which is like a set of rules. You have to follow these rules. For example I can’t have an order
unless it has a contact ID. I might have a restraint that
says you’ve got to have that. But I don’t have to have
those kind of rules in place. I can make it semistructured where
maybe some records have value, some records don’t,
columns might be considered optional. I might even have more than one copy of
the database where certain columns don’t even exist, right? And there might be data that doesn’t even
have a relationship with other data that I just need on certain occasions. There are fully unstructured databases
where there is no structure. Each end of each row just
identifies some kind of concept. Those are called schemalist databases and
just they have no rules. And that sounds really crazy, like why
would I want a database without any rules? Those type of databases focus on speed,
operating very, very fast. The whole database is usually designed to
answer one question and one question only. Remember that query I wrote? That’s a question and if I have
a very particular report I can have an unstructured database just
to feed that one report. Now if I change my mind and
want to ask it a different question. Too bad, doesn’t work, right? The database is built to
support that one question. In a relational database you can
ask it whatever question you want. The data relationships are all mapped and
you can ask it all sorts of different questions and it can generate those
results and give you what you need. So really, really flexible there. Now, in a relational database
which is the most common- when we talk about Microsoft SQL and
Oracle and mariadb, postgresql, those are all
relational databases, right? They’re not so much designed for speed
as they are for flexibility and power. They give you a lot of power to ask
all the questions that you want. When you ask them questions,
you’re basically coming in and getting data out of a table like this. And you have a column like contact_id. And then in the table you have rows, and
there will be a value in that column for what the contact_id is for
that particular order. You get that information back. There are databases that are called
noSQL databases or not only SQL. And what those do is make it
where each row isn’t necessarily aligned with a particular value. And with these, you’ll usually have
what’s called a key/value database where it actually identifies what
the column name is in the row instead. So instead of having well
defined columns like this, I would just have a row that said, order
ID five, first name Don, last name Pizzet. And it’s just all right there in
that one entry I’ve got the key and the value stored in the same
entry I’m not relying, I don’t care what
the column name is called. Cuz everything I need is right there in
the data that’s being stored with it. Those are popular with big data with
massive, massive amounts of data. But they’re usually tuned
to answer one question. Any other type of question you ask
it would be incredibly inefficient. And you can have queries
that take days to run. I can ask it the question, and three days go by before I finally
get the information back. It might sound like an exaggeration, but
I’ve worked in that environment where I’ve had queries that literally took 72 hours
to execute and you got what you wanted. But usually there’s some
better way to rearrange that database to get the information you want. So those are examples. There is one other thing which
is called a document database. And document databases where instead of
storing values like what we saw back here. Instead of storing names and
text like this, a document database can
store practically anything. It can store images in there, binary data. It can store archives,
encrypted information. And now when I ask it questions
it’s not able to do sorts and things of that nature, but
it’s able to present the data back to me. A great example of that
would be Google Maps. If you go to Google Maps and
you do a search for your city, what you’re actually doing
is running a couple of searches. One search to actually figure
out what your city is, so I’m in Gainesville Florida,
so I’m gonna pull that up. But then it has to display the map. And they have a database where each map
grid is stored in different cells of this database and it’s able to query and
return the grids. But you really see that when
you switch to satellite view. If I can remember how to
get into satellite view. Somewhere
Lower, left hand corner. Lower left, yeah, where it says satellite, thank you Ronnie. So it’s having to load
pictures of each grid. And you’ve probably seen this before
where when you start zooming in on it, where certain squares will light up and
go detailed faster than others. And that’s because they’re getting
returned a little more quickly and as we continue to zoom in which, I’m on the east
side of town now instead of where we are. You can probably find
the ITPro.TV studios. But each one of these is basically
loading a separate picture and stitching them together. They’re coming out of a database. It was there just the briefest of moment
you might have noticed the blurry line that went halfway down the screen
where one grid was already loaded and the other was still loading. It’s pulling those out of a document
database to be able to input this. So, databases don’t
necessarily just store text, sometimes they store pictures
binary data other things like that. And there we go, that’s gonna pull up,
ITPro.TV studios, where we are right now. So they’ve got this picture of our
building and you can see it with your, no cars are here they must have done
this on a weekend or something. But you can grab that picture and
you can see it. You basically pull this from a database
but you never actually realize you’re interacting with that image. All right, Don, well thank you for helping us understand more about
what a database actually is. And of course what it can do for us. And even some of the different types of
databases that are out there that we might encounter as we enter into
the IT field as well. All right Don, so here’s your chance,
last words on database introduction on the concept here. All right, you use databases every single
day whether you know it or not. If you’re watching this video, the way you
got here was some database was queried to present this video to you so
you could watch it. So they are involved in
everything that you do. The question is whether or not you find it really exciting, right? Right. If you find it exciting there’s a whole world in here of how you get the data
stored and optimized and queried. And so
in the next two episodes we’re gonna take a look at a little more of that. How the databases function and
we talk to them and so on. But if you are interested, we have a whole
series of courses in the ITPro.TV library that really go in-depth on
working with databases. It’s powerful stuff, it’s fun, it’s
neat and it’s actually pretty rewarding. You can generate this data that
companies then use to be successful. So, it’s a really cool world, definitely
something you’ll want to check out. All right, thank you again, Don, for helping us with those final pieces of
advice and finding out if that’s exciting. But, that’s enough for us. Signing off for ITPro.TV,
I’m your host, Ronnie Wong. And I’m Don Pezet. Stay tuned right here for more of the CompTIA IT Fundamentals show. [MUSIC] Thank you for watching ITPro.TV.

Daniel Ostrander

Related Posts

1 thought on “Database Concepts | CompTIA IT Fundamentals+ (FC0-U61) | Free Test Prep Course from ITProTV

  1. Mohammad Shahin Alam says:

    ❤❤❤❤❤❤❤❤❤❤Love from Bangladesh Mr. Don Pezet and Ronnie Wong.❤❤❤❤❤❤❤❤❤❤❤

Leave a Reply

Your email address will not be published. Required fields are marked *