It's me from the future.
Now, back in the past, I wanted to clarify something.
I went back and watched the video and I wanted to make sure that this
made crystal clear sense and not be as clear as mud, the differences
between a SQL server and something like a SQL light, for instance, a
SQL server is on a dedicated actual server platform, so you could be
running windows server in bare bone mode, something like command line
and put when the SQL server on top of it, and all of the resources of
that actual server are dedicated to SQL, allowing it to run in multiple.
What's called instances.
So you can have a different databases for different connections across the
entirety of the network organization.
For instance, let's say the state of Texas is requiring all school
districts to be able to send in grades to a database dedicated for each of
those different school districts.
Now that's a lot of school districts.
So a SQL server would be set up with an instance set up for each school
district and each school district connecting to that one instance would
have a database dedicated for their actual grade input, and it would be
split up even further at their discretion to the different campuses
within that school district.
Now compare that to SQL light, for instance, where are my SQL even
better, and we go in and we run that on a workstation that is compatible
because my SQL can run on a workstation or a server, but it's a workstation
platform, meaning that it doesn't run in different instances.
It just runs that one database that you're able to connect
to, to be able to do grade input.
So if you ran that for your grade collection across the state of Texas,
that database would be ginormous because you would have to have everybody
connect to it on that one singular port.
And therein lies another issue.
Whereas my SQL only allows connections to port 3306 in that one database
instance that it can only support, SQL server can support multi instances
and multiple different connections at the same time, allowing for more usage
of it over a broad spectrum network.
Now, this also implies that SQL server is a vastly bigger platform for us to be
able to store data and for larger applications, whereas something like my
SQL would be something more contained for something very much smaller, like
a game or something like that.
So you can host your own games.
This used to be something that World of Warcraft players used to do back before
they released the vanilla version of it, that they would host their own private
servers and in the background, they would use my SQL to run the actual server
platform of it in order for them and their friends to be able to play whatever
version of WoW that they played.
I was actually one of those people.
So they would run something like my SQL and only be able to run that one
instance and it connect to the actual gameplay platform that was hosting all
the different bits of information to go in and out.
Now, if you do this in SQL database, you can run multiple instances and
essentially set up multiple servers of WoW, run your own different campaigns
and modes across many different of the actual game servers themselves.
Now, taking a look at the actual lab here, I'm going into the local instance for
my SQL 80 on the actual Hyper-V host.
Remember all passwords are password.
So we're going to be going in here, typing a password, and I just want to
demonstrate for you real quick why my SQL is a client based platform, even
though that we actually have it on server.
And I can prove to you that real quick, because when you log into the lab, you
can simply do start R and type in Winver and you will see that we are on Windows
server 22, but my SQL here is still a client application.
I can further prove this inside of the actual Windows 10 workstation inside of
our lab by opening up my SQL workbench on there and connecting to the Hyper-V host.
I do this simply as by clicking the plus sign next to the MySQL connection.
And you can put in all the information here to connect to
whichever MySQL that you want to.
Now, if you notice here for a second, that it allows you to have a connection
name, which I called it, called it the Hyper-V MySQL.
And then the host name is 192.168.0.0.0.1, port 3.3.0.0.6.
All the info is already there.
So you'll see it right here as the host Hyper-V and all the information.
When you connect to it, you will get the prompt for a password and you'll notice
that it goes straight into the same one that we have over here on the actual host
Hyper-V. We did not get the option for different instances.
So in our example of the actual schools across the state of Texas, connecting to a
SQL server, if this were the case, they were using MySQL, everybody would be
connecting to this right here.
And you will see multi databases here on the left, one database for each school
district, state of Texas.
Whereas in different instances, they would have one SQL server instance for each
school district across the state.
And you wouldn't see anybody else's database within there unless you created it or
imported it.