🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🗄️ धडा 01 — database का: रेकॉर्ड रूम

📍 तुम्ही इथे आहात: 18 पैकी धडा 01 · पुढे: lesson-02-tables-rows-keys

📦 या ब्रँचमध्ये काय आहे

database कोणता प्रश्न सोडवण्यासाठी अस्तित्वात आहेत — आणि ती तीन वचने (टिकाऊ, सामायिक, उत्तर देणारी) जी कोर्सच्या पुढच्या प्रत्येक design निर्णयाचे कारण सांगतात. संपूर्ण कोर्सभर तुम्ही वापराल अशा खऱ्या files:

db/schema.sql — नोंदवह्या, नीट आखलेल्या
db/seed.sql — पाच विद्यार्थी, दहा grades
db/demo.py — प्रत्येक धड्याच्या queries, प्रत्यक्ष, खऱ्या SQLite database वर

🎒 सुरू करण्याआधी: तुम्हाला Python 3 हवे — त्याचे built-in sqlite3 module हीच संपूर्ण रेकॉर्ड रूम आहे; server नाही, Docker नाही, cloud नाही. Postgres आणि MySQL मध्ये कल्पना त्याच आहेत; जिथे फरक आहे तिथे धडे तसे सांगतात. चांगले शेजारी: API शाळा (या खोलीसमोरचा counter) आणि VectorDB शाळा (शेजारचा अर्थाचा हॉल).

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळा आपल्या विद्यार्थ्यांबद्दलचे सत्य कुठे ठेवते? जुन्या वाईट दिवसांत: चिकट चिठ्ठ्या आणि spreadsheets 📝. क्रीडा शिक्षिकेकडे एक यादी होती, office कडे दुसरी, canteen app ची स्वतःची file. तीन याद्या, कतरिनाच्या वर्गाच्या तीन आवृत्त्या. office चा laptop एका शुक्रवारी बंद पडला आणि grades सोबत घेऊन गेला. आणि एक साधा प्रश्न — "maths मध्ये A मिळालेले 3A चे सर्व विद्यार्थी" — तीन files आणि calculator उघडल्याशिवाय कोणालाच सोडवता येत नव्हता.

म्हणून शाळेने एक रेकॉर्ड रूम 🗄️ बांधली: एकच जागा, एका दप्तरदाराकडून चालवली जाणारी, तीन वचनांसह:

टिकाऊ — चिकट चिठ्ठीवर नव्हे, तर कपाटातल्या बांधलेल्या नोंदवह्यांमध्ये लिहिलेले. laptop बंद पडतो; नोंदवह्या राहतात.
सामायिक — प्रत्येक clerk, app आणि शिक्षिका त्याच नोंदवह्या पाहतात, आणि एकाच वेळी लिहिणारे दोन clerks पान फाडणार नाहीत याची दप्तरदार काळजी घेतो (धडा 07).
उत्तर देणारी — तुम्ही प्रमाणित पद्धतीने प्रश्न विचारता ("maths मध्ये A मिळालेले 3A चे सर्व विद्यार्थी") आणि दप्तरदार ते शोधतो — पटकन, कार्ड कॅटलॉगच्या मदतीने (धडा 06).

ती रेकॉर्ड रूम म्हणजेच database. नोंदवह्या म्हणजे tables, प्रश्नांची भाषा म्हणजे SQL, आणि दप्तरदार म्हणजे database engine.

🗺️ आकृती

flowchart LR
    subgraph before["📝 before: sticky notes"]
        a1["sports list: Katrina 3A"]
        a2["office sheet: Katrina 3B?"]
        a3["canteen file: gone with the laptop 💥"]
    end
    subgraph after["🗄️ after: the record room"]
        d["1 durable — on the shelf, survives the crash"]
        s["2 shared — many clerks, one truth"]
        q["3 answerable — ask in SQL, fast with a catalogue"]
    end
    before -->|"build the record room"| after

❓ काय

database हा असा program आहे जो data टिकाऊ ठेवतो, अनेक users ना तो सुरक्षितपणे वाचू आणि लिहू देतो, आणि queries ची उत्तरे देतो. SQLite (हा कोर्स), Postgres आणि MySQL हे relational databases आहेत: keys असलेल्या tables मधला data.
टिकाऊ = commit झालेले write crash नंतरही टिकते (धडा 04 मधील ACID).
सामायिक = locks आणि isolation सह एकाच वेळी access (धडा 07).
उत्तर देणारी = एक query भाषा आणि indexes (धडे 03, 06).
API शाळेच्या प्रत्येक counter मागे अशीच एक खोली असते; counter पाहुण्यांना खोलीबाहेर ठेवतो, आणि खोली सत्य जपते.

🤔 का

कारण "फक्त file मध्ये ठेवा" ही पद्धत तिन्ही वचनांवर एकाच वेळी अपयशी ठरते, आणि प्रत्येक अपयश महागडे असते: हरवलेला data, सत्याच्या दोन आवृत्त्या, आणि कोणालाच उत्तर देता न येणारे प्रश्न. पुढे येणारा scaling, backup आणि modelling चा प्रत्येक धडा म्हणजे दबावाखाली पाळलेले यांपैकी एक वचन.

🔧 कसे (या repo मध्ये)

python3 db/demo.py हे schema.sql + seed.sql वरून db/school.db बनवते आणि कोर्सचा प्रत्येक भाग चालवते. आज तुम्ही फक्त ते चालवा आणि वाचा.

🧪 करून पाहा (60 seconds — संपूर्ण कोर्स, प्रत्यक्ष)

python3 db/demo.py

तुम्हाला असे दिसायला हवे (छाटलेले):

🗄️  school.db built from schema.sql + seed.sql
═══ reads ═══   ('Aishwarya', '3A-01') ('Dipika', '3A-03')
═══ join ═══    ('Aishwarya', '3A', 'maths', 'A') …
═══ txn ═══     💥 second update failed: FOREIGN KEY constraint failed → ROLLBACK
═══ index ═══   without an index: SCAN … 2.4 ms · with the card catalogue: SEARCH … 0.0 ms
═══ locks ═══   ⏳ clerk 1 waited, then: database is locked
═══ backup ═══  after the restore — Rohan returns
✅ done — the record room survived every lesson

✅ तपासा — तुम्हाला काय दिसायला हवे

script ✅ done ने संपते; db/school.db अस्तित्वात आहे (ls -la db/); ते पुन्हा चालवले की खोली सुरुवातीपासून पुन्हा बनते (ते file delete करून पुन्हा तयार करते — शिकताना हे मुद्दाम केले आहे).

🏁 तुम्ही आत्ताच काय सिद्ध केले

खऱ्या database ला काहीही install करावे लागत नाही: एक schema file, एक seed file, आणि Python च्या built-in SQLite ने हा कोर्स शिकवणार असलेल्या प्रत्येक प्रश्नाचे उत्तर दिले.

⚠️ नेहमीच्या चुका

दुसऱ्या folder मधून चालवणे — script आपल्या files db/ च्या सापेक्ष शोधते, पण दाखवल्याप्रमाणे repo root मधूनच चालवा
school.db हाताने edit करणे आणि पुढच्या run ला ते गमावणे — त्याऐवजी schema.sql/seed.sql बदला
"database" म्हणजे "मोठा server" असे समजणे — SQLite तुमच्या program च्या आतच चालते आणि पृथ्वीवरील सर्वाधिक deploy झालेला database आहे

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: "हरवले", "विसंगत" किंवा "हळू" हे शब्द असलेली प्रत्येक incident म्हणजे तीनपैकी एक वचन मोडलेले असते. कोणते वचन मोडले ते ओळखणे ही प्रत्येक database चर्चेची पहिली पायरी आहे.

⏭️ पुढे

नोंदवही म्हणजे नक्की काय? Tables, rows आणि keys — आणि key कधीच शून्याकडे बोट का दाखवू शकत नाही.

git checkout lesson-02-tables-rows-keys

🗄️ Lesson 01 — Why databases: the record room

📍 You are here: Lesson 01 of 18 · Next: lesson-02-tables-rows-keys

📦 What's in this branch

The problem databases exist to solve — and the three promises (durable, shared, answerable) that explain every design choice in the rest of the course. Real files you will use all the way through:

db/schema.sql — the registers, drawn properly
db/seed.sql — five students, ten grades
db/demo.py — every lesson's queries, live, on a real SQLite database

🎒 Before you start: you need Python 3 — its built-in sqlite3 module is the whole record room; no server, no Docker, no cloud. The ideas are the same in Postgres and MySQL; the lessons say where they differ. Good neighbours: the API school (the counter in front of this room) and the VectorDB school (the meaning hall next door).

🧒 Explain like I'm 5

Where does the school keep the truth about its students? In the bad old days: sticky notes and spreadsheets 📝. The sports teacher had a list, the office had another, the canteen app kept its own file. Three lists, three versions of Katrina's class. The office laptop died on a Friday and took the grades with it. And nobody could answer a simple question — "every 3A student with an A in maths" — without opening three files and a calculator.

So the school built a record room 🗄️: one place, run by an archivist, with three promises:

Durable — written into bound registers on the shelf, not on a sticky note. The laptop dies; the registers stay.
Shared — every clerk, app and teacher consults the same registers, and the archivist makes sure two clerks writing at once do not tear a page (lesson 07).
Answerable — you ask a question in a standard way ("every 3A student with an A in maths") and the archivist finds it — quickly, with a card catalogue (lesson 06).

That record room is a database. The registers are tables, the question language is SQL, and the archivist is the database engine.

🗺️ Diagram

flowchart LR
    subgraph before["📝 before: sticky notes"]
        a1["sports list: Katrina 3A"]
        a2["office sheet: Katrina 3B?"]
        a3["canteen file: gone with the laptop 💥"]
    end
    subgraph after["🗄️ after: the record room"]
        d["1 durable — on the shelf, survives the crash"]
        s["2 shared — many clerks, one truth"]
        q["3 answerable — ask in SQL, fast with a catalogue"]
    end
    before -->|"build the record room"| after

❓ What

A database is a program that keeps data durable, lets many users read and write it safely, and answers queries. SQLite (this course), Postgres and MySQL are relational databases: data in tables with keys.
Durable = a committed write survives a crash (lesson 04's ACID).
Shared = concurrent access with locks and isolation (lesson 07).
Answerable = a query language plus indexes (lessons 03, 06).
Behind every counter of the API school is one of these rooms; the counter keeps visitors out of the room, and the room keeps the truth.

🤔 Why

Because "just keep it in a file" fails on all three promises at once, and each failure is expensive: lost data, two versions of the truth, and questions nobody can answer. Every scaling, backup and modelling lesson that follows is one of the three promises kept under pressure.

🔧 How (in this repo)

python3 db/demo.py builds db/school.db from schema.sql + seed.sql and runs every section of the course. Today you only run it and read.

🧪 Try it (60 seconds — the whole course, live)

python3 db/demo.py

You should see, trimmed:

🗄️  school.db built from schema.sql + seed.sql
═══ reads ═══   ('Aishwarya', '3A-01') ('Dipika', '3A-03')
═══ join ═══    ('Aishwarya', '3A', 'maths', 'A') …
═══ txn ═══     💥 second update failed: FOREIGN KEY constraint failed → ROLLBACK
═══ index ═══   without an index: SCAN … 2.4 ms · with the card catalogue: SEARCH … 0.0 ms
═══ locks ═══   ⏳ clerk 1 waited, then: database is locked
═══ backup ═══  after the restore — Rohan returns
✅ done — the record room survived every lesson

✅ Verify — what you should see

The script ends with ✅ done; db/school.db exists (ls -la db/); running it again rebuilds the room from scratch (it deletes and recreates the file — that is on purpose while learning).

🏁 What you just proved

A real database needs nothing installed: one schema file, one seed file, and Python's built-in SQLite answered every question this course will teach.

⚠️ Common mistakes

running from another folder — the script finds its files relative to db/, but run it from the repo root as shown
editing school.db by hand and losing it on the next run — change schema.sql/seed.sql instead
thinking "database" means "a big server" — SQLite runs inside your program and is the most deployed database on earth

🏭 Why this matters in production: every incident with the words "lost", "inconsistent" or "slow" in it is one of the three promises broken. Naming which one is the first step of every database conversation.

⏭️ Next

What exactly is a register? Tables, rows and keys — and why a key can never point nowhere.

git checkout lesson-02-tables-rows-keys

← Course homeall lessons Next →tables rows keys

This page is the lesson's README from the lesson-01-why-databases branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.