SQL - lesson 3 | HackIndia Skills

Key point

One idea

A SELECT query is the read side of your feature. It should return the exact rows and columns your screen, API route, or CLI command needs.

Start from the screen

Before writing SQL, write the question your feature must answer. For a campus event app, it might be: “Show upcoming events for this college, newest first.”

That question tells you the table, columns, filters, and order. Do not start with SELECT * unless you are quickly exploring data.

Example

Basic read query

This query reads only what an event list card needs. It skips internal columns like created_at if the screen does not show them.

-- queries/list_upcoming_events.sql
SELECT
  id,
  title,
  venue,
  starts_at
FROM events
WHERE college_id = 1
  AND starts_at >= '2026-01-01 00:00:00'
ORDER BY starts_at ASC
LIMIT 10;

Your to-do

Build a SELECT

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Choose the table that owns the main data.
List only the columns your feature needs.
Add WHERE to filter rows for the user or screen.
Add ORDER BY so results appear in a useful order.
Add LIMIT for list screens, search results, and previews.

0 of 5 done

Tip

Name saved queries

Put read queries in a queries folder. Give each file a task name, not a vague name like test.sql.

Good names help recruiters understand your feature fast: list_upcoming_events.sql, find_student_by_roll.sql, search_hostels.sql.

Common mistake

Avoid SELECT star

SELECT * is okay for checking a table in your SQL client. It is not good for feature code or repo demos.

It can expose fields you did not mean to show, like phone numbers. It can also make later schema changes break your app in confusing ways.