Day 78 of Learning MERN Stack

Hello Dev Community! 👋

It is officially Day 78 of my 100-day full-stack engineering run! Over the past two days, I explored isolation schemas in SQL. Today, I stepped into the absolute core of Relational Database Management Systems (RDBMS): Wiring related data models together using Primary Keys, Foreign Keys, and Advanced Cascading Rule Triggers! 🔗📊

If tables cannot safely talk to each other without corrupting references, a relational backend fails. Today, I engineered an automated constraint mechanism to solve exactly that.

---

🧠 The Core Paradigms I Unpacked Today

As illustrated in my structural script file inside "image_7db183.png", table links require two fundamental identifiers to maintain absolute validity:

• Primary Key (PK): A strictly unique constraint mapped within a table (e.g., id INT PRIMARY KEY inside my department chart) that ensures no record rows are ever duplicated or recorded as NULL.
• Foreign Key (FK): A relational pointer placed inside a secondary table (teacher) that establishes an explicit link referencing the Primary Key column of the master data source (dpt).

---

🛠️ Deep Dive: The Power of Cascading Triggers

A common backend challenge arises when data mutations occur on primary models: What happens to a teacher's profile if their department's ID gets updated or completely deleted from the database?

By looking at my query code layout inside "image_7db183.png", I programmatically integrated a self-healing automation block:

sql
FOREIGN KEY (dpt_id) REFERENCES dpt(id)
ON UPDATE CASCADE
ON DELETE CASCADE