id	name
1	Anjali
2	Rahul

id	dept
1	CSE
2	ECE

student_id	course_id
1	5

ancestor	depth
A	2

Expert Talk · Dept. of CSE, LBS College of Engineering, Kasaragod

From Idea to App
Build with AI

Databases, AI tools, and how real software gets built.

Vipindas K · Software Engineer, Hexeam Software Solutions

Classroom vs real project

You know the theory. Now the real questions.

In the classroom	In a real project
Define primary key and foreign key	What happens when a parent row is deleted?
Normalise this table to 3NF	When is it worth breaking the rule, and why?
What is an index?	Which column, and what does it cost?
Write the 4 ACID properties	Two users click Register at the same moment. Now what?
Draw a one-to-many ER diagram	One notifications table for 3 kinds of users?
SQL is the database language	SQL, MongoDB, Firebase or Redis: which, for my project?

Modern software workflow

How real software gets built

💡

Idea

Who needs it, and why

🗃️

Design

The data first, then screens

🌿

Build

One Git branch per change

🔍

Review

Pull request and automatic tests

🚀

Deploy

Staging, then production

📈

Monitor

Logs, feedback, improve

Why today goes deep on the database: code is easy to change. A live database full of real users' data isn't, so a bad design there costs the most.

And AI? It helps at every step, but the steps stay. Our live demo follows the same loop: spec, plan, build, check, deploy.

The next 75 minutes

Agenda

🏗 Real projects along the way: attendance, online shop, ticket booking, wallet, canteen. Then: team habits, skills and opportunities.

01

🗺️ DB landscape

SQL, MongoDB, Firebase, Redis. Which one when?

02

🔑 MySQL basics

Keys, indexes, normal forms.

03

🔗 Relations

One-to-many, many-to-many, polymorphic.

04

🤝 Joins

Row by row, so you never forget.

05

⚡ Same-time problems

Transactions, locks, two users, one ID.

06

🌳 Trees

Closure table: insert and delete.

07

🔐 Login

How it really works, in tables.

08

🤖 AI + live reveal

Vibe coding, AI tools, which model. Then open the tool.

Live demo · kickoff

Let's give the AI a job: JoinLab

~/live-demo · claude

# the full spec is in CLAUDE.md $ claude --permission-mode plan > Read CLAUDE.md and build JoinLab exactly as specified. Plan first: the milestones only. After I approve, do them in order, deploying with bash deploy.sh at each milestone. Keep it small. Don't ask me questions unless something blocks you.

Theater: two tables stand apart, come together, and the join happens in front of you

Builder: make tables with a GUI, and see the SQL

Lab + Missions: real SQL, graded practice

Login (bonus): keep your own data, if time allows

Status: % and stuck warnings in the bottom panel ⬇

The main four

Four databases to know first

📊

SQL

Tables with strict columns and relations. The default for most apps.

MySQLPostgreSQLSQLite

📄

MongoDB

JSON-like documents. Flexible shape, easy to spread across servers.

Document DB

🔥

Firebase

Google's cloud backend. Changes reach every phone in real time.

FirestoreRealtime DB

⚡

Redis

Lives in memory, extremely fast. Cache, OTP, sessions, queues.

Key-value

Same data, four shapes

One student, four ways to store

🧑‍🎓 Anjali · CSE · php, sql

📊 SQL: rows in tables

📄 MongoDB: one document

{ "_id": 1, "name": "Anjali", "dept": { "name": "CSE" }, "skills": ["php", "sql"] }

🔥 Firebase: synced to every device

students/1 → { name: "Anjali", dept: "CSE" } change it → all open phones update instantly

⚡ Redis: key → value, with expiry

SET otp:9876543210 "482913" EX 300 gone by itself after 5 minutes

Inside the SQL family

MySQL · PostgreSQL · SQLite

🐬 MySQL

App

SQL

Server

A separate server process. Simple and popular, the default for most websites.

🐘 PostgreSQL

App

SQL

Server

Also a server, with more power: JSONB, full-text search, maps, advanced types.

🪶 SQLite

App + data.sqliteno server, one file

A library inside your app. Zero setup. Used in phones, browsers and small tools.

Compare

Which SQL database?

	MySQL	PostgreSQL	SQLite
Runs as	Server	Server	File inside the app
Setup	Easy	Easy to medium	None
Many writers at once	Yes	Yes	One writer at a time
Strength	Simple, widely hosted	Rich features, strict rules	Tiny, portable, offline
Pick it for	Websites, college apps	Complex data, analytics, maps	Mobile apps, prototypes, small tools

💡 All three speak SQL. Learn one well and the others come easily.

Relational vs non-relational

One order, two designs

📊 Relational: split, then linked

orders
id	user
1	Anjali
2	Rahul

order_items
order	product
1	7
2	7

products
id	name
7	PenGel Pen

Rename the product: change 1 row. Every order sees it. ✅

Read an order: needs a JOIN of 3 tables.

📄 Non-relational: all in one

orders { id: 1, user: "Anjali", items: [{ name: "Pen" }] } { id: 2, user: "Rahul", items: [{ name: "Pen" }] }

Rename the product: update every document. ⚠️

Read an order: one document, no join. ✅

Relational protects correct data. Non-relational gives flexibility and easy scale.

Use cases

What would you pick?

Project	Pick	Why
College ERP, marks, fees	MySQL / PostgreSQL	Strong relations, correct data
Online payments	MySQL / PostgreSQL	Transactions keep money correct
Product catalogue, each item with different fields	MongoDB	Flexible document shape
Live chat or live score app	Firebase	Real-time sync, little backend code
OTP, cache, login sessions	Redis (alongside SQL)	Fast, expires by itself
Offline notes app on a phone	SQLite	A file on the device

Rule: start with one SQL database. Add others only for a real need.

Keys

The keys that hold data together

students
id	reg_no	name	dept_id
1	KSD22CS001	Anjali	1
2	KSD22CS002	Rahul	1
3	KSD22EC001	Fathima	2

departments
id	name
1	CSE
2	ECE

enrollments
student_id	course_id
1	5
1	7

Primary key: identifies each row. Unique, never NULL, one per table.

Unique key: no duplicates allowed, but not the row's main identity.

Foreign key: points to a primary key in another table. This is the link.

Composite key: two columns together are unique. Student 1 can't take course 5 twice.

Candidate key: any column that could be the primary key, like id or reg_no. You choose one.

Foreign keys protect data

The database says no

INSERT INTO students (name, dept_id) VALUES ('Arun', 99); ✗ ERROR: foreign key constraint fails. Department 99 doesn't exist.

🛡️ departments
id	name
1	CSE
2	ECE

And when you delete the CSE department, what happens to its students? You decide:

RESTRICT

Refuse the delete while students exist. The safe default.

CASCADE

Delete the students too. Good for order items; dangerous elsewhere.

AnjaliRahul

SET NULL

Keep the students, with dept_id = NULL. They're unassigned.

Indexing

Find one student among 10 lakh

🐢 No index: full table scan

email
rahul@…
fathima@…
arjun@…
… every row …
anjali@… ✓ found last

Rows checked: 0

🚀 With an index: a sorted tree (B-tree)

Steps taken: 0

Worst case: every row gets checked.

Just a few steps, like the index at the back of a textbook.

CREATE INDEX idx_students_email ON students (email); -- one line, one column

Index trade-offs

Why not index every column?

✅ Index it when

Used in WHERE
Used in JOIN (foreign keys)
Used in ORDER BY
Many different values

❌ Disadvantages

INSERT and UPDATE get slower
Uses extra disk space
Too many confuse the design

🚫 Skip it when

Very small tables
Few values, like yes / no
Column rarely searched

-- Composite: order matters (leftmost first) CREATE INDEX idx ON students (dept_id, name); WHERE dept_id = 1 AND name = 'Anjali' ✓ used WHERE name = 'Anjali' ✗ not used

-- Is my query using the index? EXPLAIN SELECT * FROM students WHERE email = 'anjali@…'; -- type: ALL = full scan (slow) -- type: ref = index used (fast)

🏗 Real project · college attendance

One small feature, 12 lakh rows a year

📈 Rows in a year: 0

attendance
student_id	date	period	status
1	2026-11-05	1	P
2	2026-11-05	1	P
1	2026-11-05	2	P
3	2026-11-05	2	A
1	2026-11-06	1	A
2	2026-11-06	1	P

The maths: 1,000 students × 6 periods × 200 days.

The report: Anjali's attendance this semester. With no index, MySQL reads every row.

SELECT SUM(status='P') * 100 / COUNT(*) FROM attendance WHERE student_id = 1 AND date >= '2026-06-01';

The fix: a composite index. Now MySQL goes straight to Anjali's rows.

CREATE INDEX idx_student_date ON attendance (student_id, date);

Teacher taps Save twice? UNIQUE (student_id, date, period) refuses the copy.

Normal forms · 1NF

1NF: one value in each cell

❌ students
id	name	phones
1	Anjali	9876…, 9447…
2	Rahul	9995…

→

✅ students
id	name
1	Anjali
2	Rahul

✅ phones
student_id	phone
1	9876…
1	9447…
2	9995…

Problem: try finding “who has 9447…”, or removing one number. You'd have to cut text apart.

Fix: a new table, with one row per phone.

Result: each cell holds one value, and each student can have any number of phones.

Normal forms · 2NF

2NF: depend on the whole key

❌ enrollments, key = (student_id, course_id)
student_id	course_id	student_name	grade
1	5	Anjali	A
1	7	Anjali	B
2	5	Rahul	A

✅ enrollments
student_id	course_id	grade
1	5	A
1	7	B
2	5	A

✅ students
id	name
1	Anjali
2	Rahul

Problem: the name depends only on student_id, part of the key. It repeats on every row.

Fix: move it to the students table. The grade needs both columns, so it stays.

Result: a name change touches one row, not hundreds.

One-to-one

Has one · belongs to

users
id	name
1	Anjali
2	Rahul

profiles
id	user_id FK + UNIQUE	photo
10	1	a.jpg
11	2	r.jpg

User has one profile. Read it from the users side.

Profile belongs to a user. Same link, read from the other side.

Where's the foreign key? Always on the “belongs to” table.

UNIQUE stops a second profile for the same user.

One-to-many · many-to-one

One line, two directions

departments (one)
id	name
1	CSE
2	ECE

students (many)
id	name	dept_id FK
1	Anjali	1
2	Rahul	1
3	Fathima	2

One-to-many: department has many students.

Many-to-one: each student belongs to one department.

Rule: the foreign key goes on the many side. You can't fit many ids in one cell (1NF!).

Many-to-many

A third table: the pivot

students
id	name
1	Anjali
2	Rahul

enrollments (pivot)
student_id	course_id
1	5
1	7
2	5

courses
id	title
5	DBMS
7	OS

A student takes many courses (DBMS and OS).

A course has many students (Anjali and Rahul take DBMS).

Bonus: the pivot can hold extra data, like grade or joined date.

Polymorphic · morph one / morph many

One table that points to many tables

students
id	name
1	Anjali

teachers
id	name
1	Dr. Nair

admins
id	name
4	Office

notifications
id	owner_type	owner_id	message
1	student	1	Fee due
2	teacher	1	Marks pending
3	admin	4	Server backup OK

Two columns do the work: which table (type) + which row (id). Student 1 and teacher 1 stay different.

Morph many: one student has many notifications. Morph one: one owner has one row, like a profile photo.

SELECT * FROM notifications WHERE owner_type = 'teacher' AND owner_id = 1;

⏩ Polymorphic many-to-many

Morph to many · morphed by many

posts
id	title
1	SQL tips

videos
id	title
1	Joins 101

taggables (pivot)
tag_id	item_type	item_id
7	post	1
8	post	1
7	video	1

tags
id	name
7	database
8	beginner

Morph to many: a post has many tags.

The same pivot serves videos too. No second pivot table needed.

Morphed by many: the tag “database” is used by posts and videos.

⚠️ Trade-off: owner_id can't be a real foreign key, so your code must keep it correct.

Joins · row by row

INNER JOIN: only matches survive

SELECT s.name, d.name FROM students s INNER JOIN departments d ON s.dept_id = d.id;

students
name	dept_id
Anjali	1
Rahul	1
Fathima	2
Arjun	3
Neha	2
Vishnu	NULL

departments
id	name
1	CSE
2	ECE
3	Mech
4	Civil

result: 5 rows
student	department
Anjali	CSE
Rahul	CSE
Fathima	ECE
Arjun	Mech
Neha	ECE

Vishnu: dept_id is NULL, so no partner. Dropped from the result.

Civil: no students point to it. It doesn't appear either.

Joins · keep the unmatched

LEFT · RIGHT · FULL

LEFT JOIN: 6 rows

All students. Vishnu stays, with department NULL.

Vishnu

NULL

RIGHT JOIN: 6 rows

All departments. Civil stays, with student NULL.

NULL

Civil

FULL JOIN: 7 rows

Everyone. MySQL has no FULL JOIN: combine LEFT and RIGHT with UNION.

-- A favourite interview question: students with no department SELECT s.name FROM students s LEFT JOIN departments d ON s.dept_id = d.id WHERE d.id IS NULL;

⏩ Two things you'll need soon

GROUP BY and the N+1 mistake

📊 GROUP BY + HAVING

SELECT d.name, COUNT(s.id) AS total FROM departments d LEFT JOIN students s ON s.dept_id = d.id GROUP BY d.id, d.name HAVING total >= 2;

WHERE filters rows before grouping. HAVING filters groups after.

🐌 The N+1 mistake

-- ❌ 1 query, then 1 more per student SELECT * FROM students; SELECT * FROM departments WHERE id = ?; -- … 1000 students = 1001 queries -- ✅ one JOIN gets it all at once

Works fast on your laptop, crawls with real data.

🏗 Real project · online shop

The price went up. Did the old bill change?

users
id	name
1	Anjali

orders
id	user_id
501	1

order_items
order_id	product_id	qty	price
501	7	1	₹999

products
id	name	price
7	Earphones	₹999

SELECT p.name, oi.qty * p.priceoi.price AS total FROM order_items oi JOIN products p ON p.id = oi.product_id WHERE oi.order_id = 501;

🧾 Bill #501: ₹999

The problem: Anjali paid ₹999 in January. That old bill now says ₹1,299.

The fix: copy the price into order_items at purchase.

Not a normalisation mistake: the price paid and today's price are two different facts. Do the same for the delivery address and tax.

Keep your data safe

SQL injection and backups

// ❌ the input becomes part of the SQL "SELECT * FROM users WHERE email = '" + email + "'" email = ' OR 1=1 -- → returns every user!

// ✅ prepared statement: input is only data "SELECT * FROM users WHERE email = ?" + [email]

Back up every day, automatically
Test a restore: an untested backup is only a hope
Least privilege: the app's DB user can't drop tables

Procedural language

Code that lives inside the database

CREATE PROCEDURE enroll(IN s INT, IN c INT) BEGIN IF (SELECT COUNT(*) FROM enrollments WHERE course_id = c) >= 60 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Course is full'; END IF; INSERT INTO enrollments VALUES (s, c); END; CALL enroll(1, 5); -- run it from any app

Stored procedure: a named program. Run it with CALL.

Function: returns a value, usable inside a SELECT.

Trigger: runs by itself on INSERT, UPDATE or DELETE. Good for audit logs.

Use sparingly: harder to test and review than normal app code.

Transaction

All steps succeed, or none do

Anjali

₹5000

➜

Rahul

₹2000

START TRANSACTION; UPDATE accounts SET bal = bal - 1000 WHERE name = 'Anjali'; ⚡ power cut! → ROLLBACK -- try again UPDATE accounts SET bal = bal + 1000 WHERE name = 'Rahul'; COMMIT; ✓ saved for good

Crash halfway: the debit is undone. No money vanishes.

Atomic: all or nothing

Consistent: rules always hold

Isolated: others don't see half-done work

Durable: after COMMIT, it survives a crash

Locks

One biryani left, two students

🍛 Biryani · stock = 1 🔓🔒🔓

🙋 User A

🙋 User B

step 1

SELECT stock FROM menu_items WHERE id=1 FOR UPDATE 🔒 got it

step 2

Same query: ⏳ waiting…

step 3

UPDATE menu_items SET stock = 0 WHERE id=1

step 4

COMMIT 🔓 released, ordered!

step 5

Reads stock = 0: “Sold out”

Shared lock: many can read, nobody writes.

Exclusive lock: one writer, others wait.

Row lock: only that row waits (InnoDB, needs an index).

Table lock: the whole table waits. Avoid it.

Deadlock: two users wait for each other, and MySQL cancels one. Always lock in the same order.

A real bug · race condition

Two users register at the same moment

🙋 Anjali clicks Register

🙋 Rahul clicks Register

10:00:00.01

SELECT MAX(reg_no) → 100

10:00:00.02

100 + 1 = 101

10:00:00.03

INSERT reg_no 101 ✓

INSERT reg_no 101 💥

🗄️ students · reg_no: 100, 101, 101 💥

Both read before either one has saved.

Same maths, so the same number.

No UNIQUE: two students share one ID. With UNIQUE: Rahul gets an error.

On your laptop it never happens. On results day, it happens every minute.

The fix

Same moment, two different IDs

🔢 counters.last_no = 100

🙋 Anjali

🙋 Rahul

Locks counter 🔒 reads 100

Waits for the lock ⏳

Saves 101, COMMIT 🔓

Locks counter 🔒 reads 101

Saves 102, COMMIT 🔓

START TRANSACTION; SELECT last_no FROM counters WHERE name='reg' FOR UPDATE; UPDATE counters SET last_no = last_no + 1 WHERE name='reg'; INSERT INTO students (reg_no, name) VALUES (…); COMMIT;

Plain ID: AUTO_INCREMENT. The database hands out unique numbers, with no code. Gaps can appear, and that's fine.

Formatted no. (KSD22CS101): counter row + lock, as here.

Always add UNIQUE as the final safety net.

🏗 Real project · ticket booking

Last seat, one winner

🙋 Anjali💺 A5🙋 Rahul

bookings · UNIQUE (show_id, seat_no)
show_id	seat_no	user
7	A5	Anjali

✗ ERROR 1062: Duplicate entry '7-A5' Rahul's app says: “Sorry, just sold.”

Same second: both tap A5, so two INSERTs arrive.

Anjali's lands. The seat is booked.

Rahul's is refused. UNIQUE is the final safety, even if your code has a bug.

While paying: hold the seat for 5 minutes. 1 row changed means yours; 0 means taken.

UPDATE seats SET held_by = 1, held_until = NOW() + INTERVAL 5 MINUTE WHERE id = 55 AND (held_until IS NULL OR held_until < NOW());

Why not a lock? Paying takes minutes. Locks should last milliseconds.

🏗 Real project · UPI-style wallet

Double tap, charged once

📱 Pay ₹500💰 Balance: ₹5,000

ledger · UNIQUE (idem_key)
id	user_id	amount	idem_key
1	1	+5000	topup-1
2	1	−500	pay-9f2c

✗ ERROR 1062: Duplicate entry 'pay-9f2c' The app shows the first result. No second charge.

Tap Pay: the app makes one key for this payment and sends it along.

Slow network, second tap or auto-retry: same key, so UNIQUE refuses it. The balance stays ₹4,500.

A ledger, not only a balance: every rupee movement is a row, so you can always explain the balance.

SELECT SUM(amount) FROM ledger WHERE user_id = 1;

For speed: many apps also keep a balance column, updated in the same transaction. The ledger stays the truth.

Beyond the textbook · trees

Storing a tree in flat tables

🌳 Binary

Max 2 children: left and right.

🔲 Matrix

Fixed width, like 3 children, then the next level fills.

🌿 Unilevel

Unlimited children. Also comment threads, folders.

Simple design: a parent_id column. Finding a direct parent or child is easy.

The problem: “everyone under A” needs one query per level, or recursion, and gets slower as the tree grows.

Closure table · binary tree

Store every path, not just the parent

tree_paths · 11 rows
ancestor	descendant	depth
A	A	0
B	B	0
A	B	1
C	C	0
A	C	1
D	D	0
B	D	1
A	D	2
E	E	0
B	E	1
A	E	2

Each row says: this node is above that node, by N steps. Every node also has a self row, depth 0.

B's team: WHERE ancestor='B' AND depth>0

D's upline: WHERE descendant='D' AND depth>0

Cost: more rows and more writes, for very fast reads. No recursion. Used for referrals, org charts, product categories and comment threads.

Closure table · insert

Insert a node: rows arrive

tree_paths rows: 11

ancestor	descendant	depth
A	A	0
B	B	0
A	B	1
C	C	0
A	C	1
D	D	0
B	D	1
A	D	2
E	E	0
B	E	1
A	E	2
F	F	0
C	F	1
A	F	2

New member F joins under C, on the left.

Self row: F to F, depth 0.

Copy C's rows, depth + 1: C→C 0 becomes C→F 1. A→C 1 becomes A→F 2.

INSERT INTO tree_paths (ancestor, descendant, depth) SELECT ancestor, 'F', depth + 1 FROM tree_paths WHERE descendant = 'C' UNION ALL SELECT 'F', 'F', 0;

Closure table · delete

Delete a node: rows leave

tree_paths rows: 14

ancestor	descendant	depth
A	A	0
B	B	0
A	B	1
C	C	0
A	C	1
D	D	0
B	D	1
A	D	2
E	E	0
B	E	1
A	E	2
F	F	0
C	F	1
A	F	2

Delete leaf F: its 3 rows go.

DELETE FROM tree_paths WHERE descendant = 'F';

Delete B's whole team: B, D and E go, with 8 rows.

DELETE FROM tree_paths WHERE descendant IN ( SELECT descendant FROM ( SELECT descendant FROM tree_paths WHERE ancestor = 'B' ) t);

In real apps: usually soft delete, or move the children up. Removing one person shouldn't silently remove their team.

Login

Authentication vs Authorization

🪪

Authentication

“Who are you?”

College gate: security checks your ID card.

🚪

Authorization

“What can you do?”

Inside: only lab staff can open the server room.

⏩ Login types

Many logins, all stored in tables

🔑

Password

users.pass_hash. Never plain text.

📲

OTP

A short code with expiry. Often in Redis.

✉️

Magic link

A one-time token sent by email.

🌐

Google login

users.google_id. No password stored.

👆

Passkey

Fingerprint on the device. Server keeps a public key.

🛡️

2FA

Password + a code from an authenticator app.

🏢

SSO

One login for many apps.

🎟️

API token

For mobile apps and other programs.

How a password login works

Sessions and cookies, in tables

💻Browseryou

email + password🍪 session id🍪 + next page

⚙️Serveryour code

find userhash ✓

🗄️Databaseusers, sessions

1. The form sends email + password over HTTPS

2. Compare with users.pass_hash (bcrypt), never plain text

3. Save a row in sessions, and send its id as a cookie (HttpOnly)

4. Every next request carries the cookie: “still me”

🏗 Real project · canteen pre-order

From idea to tables

“Students pre-order food from the canteen, pay online, and collect their order with a token.”

👤 users
id
name
phone

💳 payments
id
order_id
amount
idem_key

📋 orders
id
user_id
token_no
status
pickup_at

🧾 order_items
order_id
item_id
qty
price

🍛 menu_items
id
name
price
stock

Only 50 biryani? Transaction, and lock the stock row.

Token number? Never MAX + 1. Use a counter row with a lock.

Pay tapped twice? UNIQUE idempotency key.

OTP login? Start in SQL. Add Redis only when you need it.

Starting your own project

Decide these before you code

Question	Usual answer
What's the data like?	Linked data → MySQL / PostgreSQL
Need live updates, no backend?	Firebase
Which language do I know?	PHP, JS, Python: the one you know is best
Framework?	Laravel, Express, Django: login and DB tools built in
Where will it run?	A small VPS, or a free tier to start

🤖 Ask AI to think with you

I'm building a canteen pre-order app for 500 students. I know PHP. Suggest a database, framework and tables. Explain why, list the trade-offs, and don't write code yet.

AI proposes. You decide.

Industry best practices

Habits every team expects

🌿 Git and review

Every change on a branch, reviewed by someone before it merges.

🧪 Automatic tests

Checks run on every change, so old features don't silently break.

🗃️ Migrations

Database changes are versioned files, never manual edits on the server.

🔒 Secrets

Passwords and keys live in .env, never in Git.

🧭 Staging first

Try it on a copy. Never test on live data.

📈 Logs and backups

Know when it breaks, and test that the backup really restores.

🏗 Real-world project experience

What real projects teach you

🔄 Requirements change

Even after you've built it. Keep your design easy to change.

📈 Data grows

Fast with 100 rows can crawl with 10 lakh.

📖 You mostly read code

The job is understanding and changing code that already exists.

🙋 Real users surprise you

Double taps, slow networks, input you never imagined.

🎤 From my own work: a real story.

🤖 Building with AI · vibe coding

Vibe coding: fast, until it isn't

💬 Describe

prompt

🤖 AI writes

code

▶️ Run it

result

🗣️ “Fix this”

✅ Great for

Prototypes, demos, personal tools, and learning a new idea.

⚠️ Review every line

Login, payments, and anything holding real users' data.

AI often writes what we warned about today: MAX + 1 IDs, no UNIQUE, no index, input glued into SQL. Now you can catch them.

You own what you ship. JoinLab isn't pure vibes: it has a spec, a plan and automatic checks.

🤖 Building with AI · major tools

Four types of AI tool

Type	Examples	Use it for	Watch out
💬 Chat assistant	Claude, ChatGPT, Gemini	Think, plan, explain an error	Only knows what you paste in
✏️ AI code editor	Cursor, GitHub Copilot, Windsurf	Autocomplete and edits as you code	Easy to accept without reading
🖥️ Terminal agent	Claude Code, Codex CLI, Gemini CLI	Plan, change many files, run tests	Needs a clear spec and permission limits
⚡ App builder	Lovable, Bolt, v0, Replit	A working prototype from a prompt	Check its database and login

Today's JoinLab is built by a terminal agent. Start with one chat tool and one coding tool. Names change; the four types don't.

🤖 Building with AI · choosing a model

Pick the model by the job

🎯 What's the job?

🧠 Most capable

Claude Opus tier. Slowest, highest cost. For decisions that are expensive to get wrong.

Plan the database

⚖️ Balanced

Claude Sonnet tier. Good speed and quality. Your default for coding.

Build the screens

⚡ Small and fast

Claude Haiku tier. Cheapest, fastest. For simple, repeated work.

Check the result

That's today's build: Opus plans, Sonnet builds, Haiku checks. OpenAI and Google offer similar tiers.

Ask: How hard is it? How many calls, at what cost? How fast must it reply? Is the data private? If it is, read the data terms or run an open model locally.

Test on your real task, starting cheap. Move up only if the results aren't good enough. Names and prices change every few months.

Live · built by an AI agent during this class

Meet JoinLab 🚀

Watch joins happen, build tables with a GUI, write real SQL.

Theater: students LEFT JOIN departments
Lab: type your own query
Missions: can you finish all of them?

For aspiring software engineers

Skills and opportunities

🧱 What companies look for

DBMS, OOP, data structures
One language and framework, properly
SQL and Git
Reading and debugging code
Clear communication

🚪 Where you can start

Backend, frontend, full stack, mobile
QA, DevOps, data
Product, service, startup
Internships, freelance, open source

🎯 Your next 6 months

Build one real project, end to end
Deploy it, and put the link on your resume
Keep the code on GitHub
Try one internship or open source fix

Your edge: AI makes typing code cheaper. Understanding the problem and the data gets more valuable.

Recap

From idea to app: take these home

Start with one SQL database; add others on real need
Keys link data; indexes make it fast, at a cost
Normalise so each fact lives in one place
Foreign key goes on the many side; many-to-many needs a pivot
Transactions and locks keep same-time users correct
Never calculate IDs yourself. Let the database do it
UNIQUE is your final safety; copy facts that must not change, like the price paid
Vibe code prototypes, but review login, money and data; pick the model by the job

🎯 This week

Finish all JoinLab missions
Design tables for your project
Practise joins until they feel easy
Put one project on GitHub

Thank you

Questions? 🙋

Exams test what you remember. Real apps test what you understood.