Introduction to SQL

What SQL Actually Is

SQL stands for Structured Query Language. It is the language you use to talk to a relational database — a program whose entire job is to keep data safely on disk in an organised shape and hand back exactly the slice you asked for. When your college portal shows your attendance, when a shopping app lists the six orders you placed last month, when a bank statement loads on your phone, something behind that screen wrote a SQL query and ran it.

SQL was designed at IBM in the 1970s and later standardised by ANSI and ISO. That long history explains why it does not look like Python or Java. It reads almost like English, and its core has no loops, no if blocks and no classes. It was never meant to be a general-purpose programming language. It was meant to describe sets of data.

The most important idea to absorb on day one is that SQL is declarative. In Python you would open a file, walk through it line by line, test a condition and collect the matches. In SQL you write one sentence describing the result you want — "the names of students in the Computer Science branch scoring above 80, highest first" — and the database decides how to get it. A part of the engine called the query planner chooses whether to read the whole table, jump through an index, or combine two tables in a particular order.

That split matters more than it first appears. It is why a query that returns instantly on your laptop with fifty practice rows can crawl on a real table with five million: your SQL did not change, the plan the engine chose did. The lesson on indexes and EXPLAIN comes back to exactly this point.

• Declarative — you describe the result, not the steps to compute it
• Set-based — one statement can act on millions of rows with no loop anywhere in sight
• Standardised — the core (SELECT, INSERT, JOIN, GROUP BY) is nearly identical everywhere
• Dialect-flavoured — every database adds its own extras, so not every statement is portable
• Long-lived — SQL you learn today will still be correct a decade from now, which is rare in software

Tables, Rows and Columns

A relational database stores data in tables. A table has named columns going across and rows going down. One row is one real thing — one student, one order, one product. One column is one fact about every such thing — the roll number, the marks, the price.

The obvious comparison is a spreadsheet, and it is a useful starting picture, but there is one hard difference worth understanding immediately. In a spreadsheet any cell can hold anything: a number here, the word "absent" there, a blank below. In a database every column is locked to a data type, and that type is a promise the database enforces. If marks is declared as an integer, nobody can ever slip the text "absent" into it, not from your code, not from a colleague's script, not from an import at 2 a.m. Bad data is rejected at the door rather than discovered three months later in a report.

The list of columns and their types is called the table's schema. You design the schema first, then put data in. This feels rigid compared with a spreadsheet, and that rigidity is the whole point — it is what lets a hundred different programs read the same table and agree on what they are looking at.

One more piece completes the picture: each row normally has a column that identifies it uniquely, called the primary key. Two students can share the name "Rahul Verma", so the name cannot identify a row. A roll number or an auto-generated id can. Without a reliable key you cannot say "update this student" without risking updating someone else too.

-- A students table, drawn out as it would look on screen
--
-- +----+---------------+--------+-------+------------+
-- | id | name          | branch | marks | joined     |
-- +----+---------------+--------+-------+------------+
-- |  1 | Ananya Sharma | CSE    |    88 | 2026-07-01 |
-- |  2 | Rahul Verma   | ECE    |    74 | 2026-07-01 |
-- |  3 | Meera Nair    | CSE    |    91 | 2026-07-03 |
-- +----+---------------+--------+-------+------------+
--
--   id      -> the primary key: unique, never empty
--   name    -> text
--   branch  -> text
--   marks   -> a whole number
--   joined  -> a real date, not a date-shaped string

-- Ask for two columns, only for CSE students, best marks first
SELECT name, marks
FROM students
WHERE branch = 'CSE'
ORDER BY marks DESC;

The Databases You Will Actually Meet

The software that stores the tables and runs your SQL is called an RDBMS — a Relational Database Management System. There are many of them, and the good news is that the core of SQL is the same in all of them. A SELECT ... FROM ... WHERE ... ORDER BY written for MySQL will run unchanged on PostgreSQL and on SQL Server.

The bad news, and the reason beginners get stuck on Stack Overflow answers that "do not work", is that everything around that core differs. Limiting rows, formatting dates, joining strings together and generating id numbers all have different syntax in different products. These are called dialects. A large part of becoming comfortable with SQL is knowing which parts of what you have learned are universal and which are one product's habit.

• MySQL — open source, the default choice for PHP and many web applications; also the base for MariaDB
• PostgreSQL — open source, strict about correctness, strong on advanced types such as JSON and arrays
• SQLite — a database that is just a single file on disk, built into Android, iOS and Python; ideal for practice
• Microsoft SQL Server — common in enterprise and .NET environments
• Oracle Database — long established in banking, telecom and large enterprises
• Cloud versions — Amazon RDS, Google Cloud SQL and Azure SQL run these same engines as a managed service

The Four Jobs, and How Statements Are Grouped

Almost everything anyone ever does to stored data falls into four operations, remembered by the initials CRUD: create, read, update, delete. In SQL those are INSERT, SELECT, UPDATE and DELETE. If you learn nothing else from this course, learn those four properly — they are the backbone of every application you will ever build.

SQL statements are also grouped by the kind of change they make, and interviewers like these labels. DDL (Data Definition Language) statements change the shape of the database: CREATE, ALTER, DROP, TRUNCATE. DML (Data Manipulation Language) statements change the contents: INSERT, UPDATE, DELETE. SELECT only reads and is sometimes given its own label, DQL. TCL (Transaction Control Language) — COMMIT and ROLLBACK — decides whether a group of changes is kept or thrown away.

The practical reason to remember the split is danger. DML changes can usually be undone inside a transaction. Most DDL cannot, and in MySQL a DROP TABLE also silently ends any transaction you were in. That distinction is worth carrying into your first job.

• DDL — CREATE, ALTER, DROP, TRUNCATE: define or destroy the structure itself
• DML — INSERT, UPDATE, DELETE: add, change or remove the rows inside a structure
• DQL — SELECT: read data without changing anything
• TCL — COMMIT, ROLLBACK, SAVEPOINT: keep or discard a whole group of changes at once
• DCL — GRANT, REVOKE: control which database user is allowed to do what

-- One statement from each family, on our students table

-- DDL: define the structure
CREATE TABLE students (
    id     INT PRIMARY KEY,
    name   VARCHAR(100),
    branch VARCHAR(10),
    marks  INT
);

-- DML: put a row in
INSERT INTO students (id, name, branch, marks)
VALUES (1, 'Ananya Sharma', 'CSE', 88);

-- DQL: read it back
SELECT name, marks FROM students WHERE branch = 'CSE';

-- DML: change it
UPDATE students SET marks = 90 WHERE id = 1;

-- DML: remove it
DELETE FROM students WHERE id = 1;

Writing Your First Statements

SQL has very few rules about how you lay code out, so teams adopt conventions instead. Statements end with a semicolon, which tells the client where one statement stops and the next begins — essential when you paste five statements into a file and run them together. Line breaks and indentation mean nothing to the engine, so use them freely to keep long queries readable.

Keywords are not case-sensitive: select, SELECT and Select are the same word. The near-universal convention is uppercase keywords and lowercase names, because it makes the skeleton of a query jump out at a glance. Whether table names are case-sensitive is a different question and it depends on the database and even the operating system, so the safe habit is to pick lowercase names with underscores and use them consistently.

Text values go in single quotes: 'CSE'. Numbers do not. Double quotes are not a reliable substitute — in PostgreSQL and standard SQL, double quotes mean "this is an identifier", not "this is text", so "CSE" there means a column named CSE. Sticking to single quotes for text avoids a confusing class of errors.

-- Two comment styles
-- a single-line comment (note the space after the two dashes)
/* a block comment,
   which can run over several lines */

-- Whitespace is free; these two are identical to the engine
SELECT name, marks FROM students WHERE branch = 'CSE';

SELECT name, marks
FROM   students
WHERE  branch = 'CSE';

-- A statement with no table at all, useful for testing a connection
SELECT 'Hello, SQL' AS greeting;

-- Today's date (MySQL and PostgreSQL)
SELECT CURRENT_DATE AS today;

Where SQL Shows Up in Real Work

SQL is unusual among the things you will study because it is used by people who are not developers at all. A backend engineer writes it inside application code, but so does a business analyst pulling last quarter's numbers, a support engineer checking why one customer's order vanished, and a product manager counting how many users finished onboarding.

For a student in India heading towards internships and placements, that breadth is the practical argument for taking this course seriously. Backend, data analytics, data engineering, testing and support roles all screen for SQL, and the screening is usually a live query rather than theory. Interviewers reach for the same handful of topics again and again — joins, GROUP BY with HAVING, the behaviour of NULL, and finding the second-highest value in a column — and every one of those is covered in the lessons ahead.

• Web and app backends — accounts, orders, payments, content, notifications
• Data analysis and reporting — daily revenue, active users, drop-off at each step of a signup flow
• Data engineering — moving and reshaping data between systems, where SQL is often the transformation language
• Testing and support — reproducing a bug by looking at the exact rows a user's account produced
• Interviews — a whiteboard or shared editor where you write a query and explain your reasoning aloud