So, relational databases are a technique.
So when we're figuring out how to best use this random access storage,
we're computer scientists, we would argue, we would say, I have an idea,
sort of like the picture I just drew for you.
Another one says, I have a different idea.
And so there was in the 60s and
the 70s a debate as to the best way to make maximum use.
And there was things called index sequential and network databases,
etc., etc., etc.
And out of that debate came a standard, a standard way of thinking about it.
And it's really quite ironic that the relational databases is a rather
theoretical, not practical thing.
And I'm kind of a computer scientist and
so it always appeals to me to do basic simple things.
And I know when I first saw my first relational database I'm like
this is way too fancy for me, this will never work.
Now give me something crude and practical, and I can just sort of code and
do the thing I want to do.
And those first relational databases were pretty terrible.
But then as they got better, I'm like, wow, this is so magical, and
I don't even want to begin to know how this magical stuff works.
And so that's what we get, there's a powerful
underlying mathematical theory that makes relational databases work.
Now, our view onto relational databases is a language.
And so instead of you knowing how that data is stored on the hard drive,
you're going to talk to a very complex and
powerful piece of software called a database server.
So MySQL is this database server, and it knows where all that stuff is at and
it's got indexes, hundreds of millions of hours of computer science when it's
writing MySQL or Oracle or some other database system.
But what we did is we end up with this really simple, but beautiful,
elegant way to say, hey this is the data I want.
You are a genius, you go figure out how to get it to me and
get it back to me as fast as possible.
That is SQL, structured query language.
SQL is a interesting bit of computer technology and I've got a video interview
that I did with Elizabeth Fong of the National Institute of Standards and
Technology.
I encourage you go watch the video, but the short summary of the video is
that while the US Government, in the form of NIST, can take some credit for SQL,
what Liz will tell you is that the vendors were sort of fighting amongst themselves,
and they were fighting with the government.
And with they were trying to do is, each of them had their favorite idea, and
they're telling the government you should adopt our favorite idea,
because those other company's favorite ideas are really bad.
Another company's saying, no, no, no, their favorite idea is bad,
you should adopt our idea.
And the government, who was buying lots of technology basically said,
look we are not going to pick vendor A over vendor B.
What we're going to do is you're all going to get into a room and
you're going to agree on a way for us to talk to all three pieces of software.
We're not going to tell you what that's going to be, but until you come out of
that room with one agreement, we're going to not buy any of your products.
And so that's how SQL happened.
The industry came together, as Liz will say in the video,
she will say that it was the perfect time in that it wasn't too early, meaning that
all the vendors had good ideas about what they thought was good database.
And it wasn't too late, meaning none of the vendors had sort of by hook or
crook become dominant.
And so SQL is this magical thing.
And again, I told you before, I just love this language.
And it came out of this really interesting [LAUGH] consensus process
that was convened by the US National Institute of Standards and Technology,
but not created by the National Institute of Technology and Standards, NIST.
So SQL is this abstraction.
It wraps complex software, lots of storage in a very elegant thing.
And some of you maybe have used Microsoft Access or something, and
you've even typed a select statement or an update statement.
And you didn't even realize that you'd learned a programming language and
like I said it's one of the more elegant ones.
And what it does is it basically says, the things we do in databases are we
put stuff in, we delete stuff, we update stuff, and we read it.
CRUD, create, read, update, delete, it's in order so
it sounds better, create, read, update, delete.
We don't call it read,
we call it select, but CRUD is the idea of the four basic operations to databases.
And SQL said, look, let's make these four operations that are so common and
done all the time, super simple.