SQL Beginner's Tutorial: Relational Databases & SQL

Hi Everyone!!!

Is anyone ready to learn some SQL? I know I'm ready to teach some of the basics and maybe some slightly-more-advanced techniques. I'm not an expert by any stretch of the imagination, so these might sound like very novice tutorials to someone that's been using SQL for a number of years.

Source

Wait, did I hear some of you right? You don't know what SQL is? Well, SQL is the language that is used to interact with the SQL Relational Database.

Source

What? You don't know what a Relational Database is? Ok, now you're pulling my leg, aren't you??

No? Ok, then let's step back another couple of stairs and start at the very beginning.

Video Source

Relational Databases at their Core

So, when it comes down to it, a Relational Database is a way to store data (information) in a way that is relatively easy to access. In a nutshell, it's like an Excel Workbook or other type of Spreadsheet. Where a spreadsheet would have a worksheet with rows and columns, a Database has a table with rows and columns that can store data. Each column represents an item in a collection of fields based by name.

eg. A table might be a collection of assets and attributes for a game character (height, weight, eye color, lock-picking skills, etc.) that apply to a game engine. A column might be called "lock_picking_skill" and store a numeric value that applies to a percentage of possible skill points available to a maximum of 100.0%.

Not the Right kind of Table!

Each row in this example, if we follow it through, would be a different character. So the task in most cases is to incorporate all of the specific details as they might relate to what the table is supposed to show.

I don't know of more than a small handful of businesses that don't use Relational Databases in their company. Those that do are either very small or very disorganized (generally speaking). Databases allow you to keep all records of clients, customers, invoices, products, prices, orders, shipments, accounting information, and so much more. Most of the clients I work with have an ERP (Enterprise Resource Planning) system in place to store all information about the Business itself and, often, much more. These ERP Systems are quite massive and usually contain far more tables (sometimes hundreds) that a client will not even use or know about.

These database and ERP systems are so vital to their company's revenue that a DBA (DataBase Administrator) is one of the more sought-after positions around; and clients will pay through the nose for a good one. If you're looking for a career path that could be very lucrative, you should really consider a DBA role. Mind that it's a very hard position, first, to get into (so much to learn) and, second, to perform (so many vital tidbits that could literally destroy a company if they went bad). It's not for the faint-hearted.

Source

SQL as a Relational Database

So now that I think you've been inundated enough for one Post with what a Relational Database is, at least an overhead view of it, and what it can do for you or your business, I think I will move on to discuss SQL before signing off. Don't worry, I won't fry your brain too much. I'll try to be quick to end this first SQL Tutorial.

Ok, so SQL is short for Structured Query Language. What does that mean? A query is a question, if you're not familiar with the word (I was vaguely aware of what it meant when I started using SQL myself, so no shame in not knowing). So here we have a language that is structured to answer some question... if it helps to think of it in those terms, that is.

In our usage, it means we have a Database language to retrieve data from a set of tables that will tell us what we want to know. We will use the game engine as a foundation for my following example:

Let's say we want to store information about in-game weapons and their strengths. We decide we need a table that holds a unique item code, a description that the user will see when the mouse hovers over it, a customization for color, an amount of ammunition, and speed of the shot. We will assume the table looks like the Image 1 below. Let's now assume we want a full list of all of the items (Image 2 below). You need a way to pull that information. This is where SQL comes into play.

[Image 1]

[Image 2]

I hope this is beginning to make sense!! The next Tutoria I will begin to dive into SQL directly and explain some of the terms and jargon.

Thanks! See you on the flip-side!