Getting to Know Databases

Hey everyone! Today we're kicking off an awesome new SQL course.

This course is for people (you're not a robot, right?) who don't know SQL at all but really want to fix that 🧠. You'll start from the very basics and end up learning about stored procedures, nested transactions, triggers, and automating report creation.

You'll get hundreds of hands-on tasks to help you build strong connections between theory and real-world SQL use. And at the very end, you'll tackle a big final project with 100+ tables😅.

Our goal is to make you confident with SQL so you can handle any data task. By the end, SQL will feel like second nature. You won't have to overthink writing queries, designing databases, or solving tough analytics problems — it'll all just click and happen fast.

How we teach

Some topics will be mentioned briefly at first, then covered in detail in later lectures. For example, when we talk about the relational data model, we can't skip mentioning relationships between tables. Same thing at the start — we'll show super simple database schemas or examples, leaving out details so you don't get overwhelmed.

This step-by-step approach helps you learn — to explain one topic, you often need to give a basic idea of others. So don't worry, we'll fill in all the gaps as we go.

Course Structure

The course is organized by levels, each with several lectures. In each lecture, you'll get theory, practical tasks, and quizzes to lock in what you learn.

At the first levels, you can solve all the tasks right on the website — no extra programs needed. After a few levels, we'll walk you through installing PostgreSQL, a pro IDE, and the plugins you need. Step by step, in order.

Why PostgreSQL?

PostgreSQL is a cutting-edge, super popular database, and it's got everything we need for any project. Banks, startups, shops, game studios — they all use it. With it, you could build Instagram or even a nuclear power plant for coffee machines. And if you want more, it's easy to switch from PostgreSQL to "heavier" stuff like Microsoft SQL Server or even Oracle DB(!).

We'll do everything using PostgreSQL 17 as our database. And you should too!

That's all coming up, but today we're starting from the very beginning...

So what are these databases anyway?

Imagine you keep all your important stuff — passwords, shopping lists, exes' numbers, and favorite recipes — in one giant Excel sheet called "life.xlsx"📉. Every day, the sheet gets bigger, slower, breaks down, and at some point you realize: it's time to grow up and store your data in a better way. Time to switch to databases.

A database isn't just a table. It's like Excel, but Super-Excel: it can search, filter, and update data super fast. It doesn't freak out with millions of rows, doesn't lag, and never says "file corrupted" 💔. Basically, it's like a leveled-up assistant who never forgets where you saved that number from that one person you met back in good old pre-covid 2019.

Why do I need them?

— you might ask. Do I even need them? I mean, I never use them... Or do you?

Everything on your phone is stored in databases. Photos, messages, emails, notes — EVERYTHING is in databases. Even if you've moved to the cloud, don't relax — now your data lives in cloud databases😬. The whole internet, all the world's data, is in databases. And if you're in IT, you can make good money off that fact 💰.

No, really, it's true! Check it out:

1. Online stores: when you add an item to your cart, a database saves your choice and later sends the data for payment.
2. Social networks: likes, comments, friends — all that is stored in databases.
3. Banking systems: databases let you track balances, do transactions, and get instant info.

All this is possible thanks to databases, which provide:

• Storage: your data doesn't get lost like a whole box of papers.
• Management: data is organized, structured, and accessible.
• Retrieval: you can quickly and easily get specific info.

Core Elements of a Database

A database is built on a few basic building blocks, which you'll learn about now. At this stage, let's keep it simple — a database is kinda like Excel tables (just way better!).

Tables

Picture an Excel table: rows and columns, all neat and tidy. That's pretty much how a table works in a database. A table is the main structure for storing data in a database.

Each table:

• Has its own name (like students or courses).
• Is made up of rows and columns.

Rows

Rows are records or objects you store. One row = one object/entity, like info about a student.

Example of a row in a students database:

id: 1, name: Alex, age: 20, group: A1

Columns

Columns are properties or attributes of the object. They're also called fields. For example:

• id — unique student number.
• name — their name.
• age — age.
• group — group name they're in.

This way, we can split data into parts and always know where to look for what.

Here's what our students table looks like:

How does this work in practice?

For Excel tables, we have a program (Microsoft Excel itself) and its documents. Same with databases. The database program is called a DBMS (Database Management System), and its "documents" are just databases.

A DBMS lets you:

1. Add new rows to tables (like a new student).
2. Edit data in any column.
3. Search for info, like: "Find all students from group A1".
4. Delete rows if you don't need them anymore.

How working with data through a DBMS goes

You, as a user or dev, don't work directly with the files where data is stored. Instead, you make a "query" — what you want to get or change — and send it to the DBMS. Usually, you use a special query language for this, and the most popular one is SQL, which is what we're gonna learn. The DBMS takes your SQL query, "gets" it, talks to the database, does what you asked, and then gives you the result.

Here's a super simple diagram of working with a database:

1. User creates a query.
2. The query goes to the DBMS.
3. The DBMS talks to the database.
4. The database sends info back to the DBMS.
5. The DBMS processes the data based on the query.
6. The result goes back to the user.

Why do we need databases?

By now, some of you might be thinking: "Isn't this just a fancier Excel? Why make it so complicated?"

Here are a few reasons why databases are a must:

1. Handling huge amounts of data. Imagine managing data for millions of users. Excel tables can't handle that.
2. Easy access to info. If your query is "Find all students over 20 from group A1", databases do it in milliseconds. In Excel — good luck.
3. Organization and data integrity. Databases make sure your info stays organized and consistent.
4. Multi-user access. You and your coworker can work with the same database at the same time, no conflicts. Its structure allows that.

Imagine you're building an online store. You need to store info about products (names, prices, categories), your customers (names, contact info), and of course, orders (who bought what and when). If you try to cram all that into one big table, it'll get bloated fast, data will repeat, and it'll be a pain to find or update stuff without mistakes.

Databases offer a more elegant solution: split info into logical blocks (tables). Each table stores data about one specific type of object (like just products or just users). The cool part is, you can link these tables to show real-world relationships, like which user ordered which product.

Why do you even need all this?

If you write any kind of backend or work with data — databases will be there.

Here's who definitely needs this:

• 💻 Web devs — to save users, posts, carts, and basically everything.
• 📊 Analysts — to pull the right numbers and build reports.
• 🛠️ Admins — to keep databases fast and crash-free.
• 🧠 Programmers — so apps aren't just alive, but smart and dynamic.

And yeah — databases are a favorite at interviews. Almost always, you'll be asked to write an SQL query or explain what a JOIN is.

So if you want to level up — it's best to get friendly with databases. It's one of those skills that makes you a truly confident developer.