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

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

📇 धडा 02 — Tables, rows आणि keys: ओळ क्रमांक असलेल्या नोंदवह्या

📍 तुम्ही इथे आहात: 18 पैकी धडा 02 · मागे: lesson-01-why-databases · पुढे: lesson-03-sql-reads

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

धडा 01, आणि रेकॉर्ड रूमचा आकार: tables (नोंदवह्या), rows (ओळी), columns (छापलेली शीर्षके), primary keys (ओळ क्रमांक) आणि foreign keys ("नोंदवही X, ओळ 3 पाहा").

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

रेकॉर्ड रूम उघडा आणि तुम्हाला तीन नोंदवह्या 📇 दिसतात:

classes — प्रत्येक वर्गासाठी एक ओळ: ओळ 1 वर 3A, ओळ 2 वर 3B.
students — प्रत्येक विद्यार्थिनीसाठी एक ओळ: नाव, roll number, आणि कोणता वर्ग — "classes नोंदवही, ओळ 1 पाहा" असे लिहिलेले, "3A" हा शब्द copy करून नव्हे.
grades — प्रत्येक grade साठी एक ओळ: "students, ओळ 2 पाहा · maths · term 1 · A+".

प्रत्येक नोंदवहीतील ओळ क्रमांक म्हणजे primary key: तो कधीच पुन्हा वापरला जात नाही, कधीच बदलत नाही, आणि दुसरी नोंदवही फक्त त्याकडेच बोट दाखवते. दुसऱ्या नोंदवहीकडे बोट दाखवणारी नोंद म्हणजे foreign key — आणि दप्तरदार एक नियम पाळायला लावतो: अस्तित्वात नसलेल्या ओळीकडे कोणतीही ओळ बोट दाखवू शकत नाही. "classes, ओळ 99 पाहा" असे लिहायचा प्रयत्न करा, आणि पेन नाकारला जातो.

प्रत्येक छापलेल्या शीर्षकाला एक type (TEXT, INTEGER) आणि नियम (NOT NULL, UNIQUE, CHECK) असतात. कोणत्याही program ला करावे लागण्याआधीच नोंदवही स्वतःच मूर्खपणा नाकारते — दुहेरी roll number, Z हा grade.

🗺️ आकृती

erDiagram
    classes ||--o{ students : "class_id → classes.id"
    students ||--o{ grades : "student_id → students.id"
    classes { int id PK "line number" string name "UNIQUE: 3A, 3B" }
    students { int id PK string name string roll_no "UNIQUE" int class_id FK }
    grades { int id PK int student_id FK string subject int term "CHECK 1-3" string grade "CHECK A+..C" }

❓ काय

Table = एक नोंदवही; row = एक ओळ (एक गोष्ट); column = type असलेले एक शीर्षक. प्रत्येक प्रकारच्या गोष्टीसाठी एक table.
Primary key: row ला अनन्यपणे ओळखणारा आणि कधीच न बदलणारा column (किंवा columns चा संच). integer ids हा कंटाळवाणा पण बरोबर default आहे; नैसर्गिक keys (roll numbers) ना त्याऐवजी UNIQUE constraint मिळतो.
Foreign key: दुसऱ्या table ची primary key धरणारा column. REFERENCES classes(id) मुळे database अनाथ rows नाकारतो. grades वरील ON DELETE CASCADE म्हणजे विद्यार्थिनी delete केली की तिचे grades सुद्धा जातात — हा निर्णय तुम्ही प्रत्येक नात्यासाठी, मुद्दाम घेता.
Constraints: NOT NULL, UNIQUE, CHECK (grade IN (...)), composite UNIQUE (student_id, subject, term) — "प्रत्येक विद्यार्थिनीला प्रत्येक विषयात प्रत्येक term ला एकच grade" हे थेट कपाटातच लिहिलेले.
नाती: एक class → अनेक students → अनेक grades. "अनेक" बाजू foreign key धरते.
SQLite टीप: foreign keys फक्त PRAGMA foreign_keys = ON नंतरच लागू होतात (आमचा code प्रत्येक connection वर हे करतो); Postgres आणि MySQL ते नेहमीच लागू करतात.

🤔 का

कारण तीस rows मध्ये copy केलेली माहिती शुक्रवारपर्यंत त्यापैकी एकात तरी चुकीची असेल, आणि कुठेच बोट न दाखवणारी row म्हणजे report ची वाट पाहणारा crash. Keys आणि constraints नियमांना प्रत्येक program मधून बाहेर काढून सर्व programs वापरतात त्या एकाच जागी नेतात. म्हणूनच API शाळेचा counter लहान राहू शकतो: खोली आधीच मूर्खपणा नाकारते.

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

db/schema.sql वरपासून खालपर्यंत वाचा: चार CREATE TABLE, प्रत्येकी आपली primary key, foreign keys, constraints — आणि दोन indexes जे आम्ही धडा 06 मध्ये समजावतो.

🧪 करून पाहा

python3 db/demo.py model      # watch the schema refuse a duplicate roll number and an impossible grade
python3 - <<'EOF'
import sqlite3; c = sqlite3.connect("db/school.db"); c.execute("PRAGMA foreign_keys = ON")
print(c.execute("PRAGMA table_info(students)").fetchall())          # the printed headings
try: c.execute("INSERT INTO students (name, roll_no, class_id) VALUES ('Ghost', '9Z-01', 99)")
except sqlite3.IntegrityError as e: print("refused:", e)              # a line may not point nowhere
EOF

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

table_info मध्ये id, name, roll_no, class_id त्यांच्या types आणि notnull flags सह दिसतात; class_id = 99 असलेला insert refused: FOREIGN KEY constraint failed छापतो; demo.py model आणखी दोन नकार दाखवतो (UNIQUE आणि CHECK).

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

खोलीचा आकार कपाटातच लिहिलेला आहे: keys नोंदवह्या जोडतात, आणि constraints कोणत्याही program ला दिसण्याआधीच वाईट ओळी नाकारतात.

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

classes नोंदवहीकडे बोट दाखवण्याऐवजी वर्गाचे नाव students table मध्ये copy करणे
primary keys पुन्हा वापरणे किंवा बदलणे — key म्हणजे ओळ क्रमांक, label नव्हे
"speed साठी" foreign keys वगळणे — तुम्ही नंतरची data साफसफाई विकत घेतली आहे
value आवश्यक असताना NULL — NOT NULL म्हणा आणि ते खरे करा

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: "report चुकीचा आहे" अशा बहुतेक tickets चे मूळ दोन ठिकाणी साठवलेली माहिती किंवा delete झालेल्या row कडे बोट दाखवणारा reference असते. Constraints हा तुम्ही कधीही लिहाल असा सर्वात स्वस्त test suite आहे.

⏭️ पुढे

आता नोंदवह्यांना आकार आला आहे, त्यांना प्रश्न विचारा: SQL reads — SELECT, WHERE, ORDER BY, LIMIT, आणि नोंदवह्यांमध्ये JOIN.

git checkout lesson-03-sql-reads

📇 Lesson 02 — Tables, rows & keys: registers with line numbers

📍 You are here: Lesson 02 of 18 · Previous: lesson-01-why-databases · Next: lesson-03-sql-reads

📦 What's in this branch

Lesson 01, plus the shape of the record room: tables (registers), rows (lines), columns (the printed headings), primary keys (line numbers) and foreign keys ("see register X, line 3").

🧒 Explain like I'm 5

Open the record room and you see three registers 📇:

classes — one line per class: line 1 says 3A, line 2 says 3B.
students — one line per student: name, roll number, and which class — written as "see the classes register, line 1", not as the word "3A" copied out.
grades — one line per grade: "see students, line 2 · maths · term 1 · A+".

The line number in each register is the primary key: it is never reused, never changes, and is the only thing another register points at. A pointer to another register is a foreign key — and the archivist enforces a rule: a line may not point at a line that does not exist. Try to write "see classes, line 99" and the pen is refused.

Every printed heading has a type (TEXT, INTEGER) and rules (NOT NULL, UNIQUE, CHECK). The register itself refuses nonsense — a duplicate roll number, a grade of Z — before any program has to.

🗺️ Diagram

erDiagram
    classes ||--o{ students : "class_id → classes.id"
    students ||--o{ grades : "student_id → students.id"
    classes { int id PK "line number" string name "UNIQUE: 3A, 3B" }
    students { int id PK string name string roll_no "UNIQUE" int class_id FK }
    grades { int id PK int student_id FK string subject int term "CHECK 1-3" string grade "CHECK A+..C" }

❓ What

Table = a register; row = one line (one thing); column = a heading with a type. One table per kind of thing.
Primary key: a column (or set) that identifies a row uniquely and never changes. Integer ids are the boring, correct default; natural keys (roll numbers) get a UNIQUE constraint instead.
Foreign key: a column holding another table's primary key. REFERENCES classes(id) makes the database refuse orphans. ON DELETE CASCADE on grades means deleting a student removes their grades — a decision you make per relationship, on purpose.
Constraints: NOT NULL, UNIQUE, CHECK (grade IN (...)), composite UNIQUE (student_id, subject, term) — "one grade per student per subject per term" written into the shelf itself.
Relationships: one class → many students → many grades. The many side holds the foreign key.
SQLite note: foreign keys are enforced only after PRAGMA foreign_keys = ON (our code does it on every connection); Postgres and MySQL enforce them always.

🤔 Why

Because a fact copied into thirty rows will be wrong in one of them by Friday, and a row that points nowhere is a crash waiting for a report. Keys and constraints move the rules out of every program and into the one place all programs share. That is why the API school's counter can stay small: the room already refuses nonsense.

🔧 How (in this repo)

Read db/schema.sql top to bottom: four CREATE TABLEs, each with its primary key, its foreign keys, its constraints — and two indexes we explain in lesson 06.

🧪 Try it

python3 db/demo.py model      # watch the schema refuse a duplicate roll number and an impossible grade
python3 - <<'EOF'
import sqlite3; c = sqlite3.connect("db/school.db"); c.execute("PRAGMA foreign_keys = ON")
print(c.execute("PRAGMA table_info(students)").fetchall())          # the printed headings
try: c.execute("INSERT INTO students (name, roll_no, class_id) VALUES ('Ghost', '9Z-01', 99)")
except sqlite3.IntegrityError as e: print("refused:", e)              # a line may not point nowhere
EOF

✅ Verify — what you should see

table_info lists id, name, roll_no, class_id with their types and notnull flags; the insert with class_id = 99 prints refused: FOREIGN KEY constraint failed; demo.py model shows two more refusals (UNIQUE and CHECK).

🏁 What you just proved

The shape of the room is written into the shelf: keys connect registers, and constraints refuse bad lines before any program sees them.

⚠️ Common mistakes

copying the class name into the students table instead of pointing at the classes register
reusing or changing primary keys — a key is a line number, not a label
skipping foreign keys "for speed" — you have bought a data clean-up later
NULL where a value is required — say NOT NULL and mean it

🏭 Why this matters in production: the majority of "the report is wrong" tickets trace back to a fact stored in two places or a reference that pointed at a deleted row. Constraints are the cheapest test suite you will ever write.

⏭️ Next

Now that the registers have a shape, ask them questions: SQL reads — SELECT, WHERE, ORDER BY, LIMIT, and JOIN across registers.

git checkout lesson-03-sql-reads

← Previouswhy databases Next →sql reads

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