डाटाबेस कन्स्ट्रेइन्ट्स के हुन्छन्?

Question

Accepted Answer

**Constraints** डाटाबेसले टेबलमा डाटामा लागू गरेका नियमहरू हुन् — डाटाबेस स्तरमा डाटा अखण्डता गारन्टी गर्दछन् (केवल एप्लिकेशन कोडमा होइन)। मुख्य कन्स्ट्रेइन्ट्सः `PRIMARY KEY`, `FOREIGN KEY`, `UNIQUE`, `NOT NULL`, `CHECK`, र `DEFAULT`।

## मुख्य constraints

```sql
CREATE TABLE users (
    id       INT PRIMARY KEY,                    -- unique + not null identifier
    email    VARCHAR(255) UNIQUE NOT NULL,        -- must be unique AND present
    age      INT CHECK (age >= 0 AND age <= 120), -- must satisfy a condition
    country  VARCHAR(2) DEFAULT 'US',             -- default value if not provided
    role     VARCHAR(20) NOT NULL DEFAULT 'user',
    manager_id INT REFERENCES users(id)           -- FOREIGN KEY (referential integrity)
);
```

```text
PRIMARY KEY  → uniquely identifies a row (unique + not null, indexed)
FOREIGN KEY  → references another table's key (referential integrity)
UNIQUE       → no duplicate values allowed in this column
NOT NULL     → the column must have a value (can't be NULL)
CHECK        → the value must satisfy a condition (age >= 0, status IN (...))
DEFAULT      → a value used when none is provided on insert
```

## डाटाबेस स्तरमा किन लागू गर्ने (केवल एप्लिकेशनमा होइन)?

```sql
-- ❌ relying only on application code to enforce uniqueness:
--    a race condition or a bug or a different app could insert a duplicate

-- ✅ a UNIQUE constraint guarantees it at the DB level — ALWAYS enforced,
--    regardless of which code or how many apps access the database
email VARCHAR(255) UNIQUE
```

डाटाबेस constraints डाटा अखण्डताको **अन्तिम सुरक्षा लाइन** हुन् — कुनै पनि कोडले डाटा इन्सर्ट गरे पनि (बहु एप्लिकेशन, स्क्रिप्ट, म्यानुअल परिवर्तन, वा बग भरिएको कोड) ती सधैं लागू हुन्छन्, र एप्लिकेशन-स्तरीय जाँचले छोड्ने race conditions ह्यान्डल गर्दछन्।

## डोमेन नियमहरूको लागि CHECK constraints

```sql
CHECK (price > 0)                          -- prices must be positive
CHECK (status IN ('active', 'inactive'))    -- only valid statuses
CHECK (end_date > start_date)               -- logical consistency
```

`CHECK` व्यावसायिक/डोमेन नियमहरू सीधा स्कीमामा लागू गर्दछ।

## यो किन महत्त्वपूर्ण छ

Constraints **डाटा अखण्डता** कायम राखनको लागि आवश्यक छन् — ती गारन्टी गर्दछन् कि डाटाबेसमा डाटा नियमहरू (विशिष्टता, उपस्थिति, वैध मानहरू, वैध सन्दर्भहरू) डाटाबेस स्तरमा पूरा गरे, जो विश्वसनीय एप्लिकेशनहरूको लागि मौलिक छ, त्यसकारण तिनलाई बुझ्न महत्त्वपूर्ण छ।

Constraint प्रकारहरू (`PRIMARY KEY`, `FOREIGN KEY`, `UNIQUE`, `NOT NULL`, `CHECK`, `DEFAULT`) र प्रत्येकले के लागू गर्दछ भनेर जान्नु उचित स्कीमा डिजाइनको लागि आवश्यक छ।

सबैभन्दा महत्त्वपूर्ण अवधारणात्मक बिन्दु यो हो कि **डाटाबेस स्तरमा किन लागू गर्ने केवल एप्लिकेशन कोडमा होइन**: डाटाबेस constraints डाटा अखण्डताको **अन्तिम सुरक्षा लाइन** हुन् — कुनै पनि कोड वा कति पनि एप्लिकेशन डाटामा पहुँच गरे पनि ती सधैं लागू हुन्छन्, ती एप्लिकेशन जाँचहरूले छोड्न सक्ने बगहरू पकडदछन्, र महत्त्वपूर्ण रूपमा ती **race conditions** ह्यान्डल गर्दछन् जो एप्लिकेशन-स्तरीय सत्यापनले सक्दैन (उदा. दुई सिमल्टेनस इन्सर्टहरू दुवै एप्लिकेशन-स्तरीय विशिष्टता जाँच पास गर्दछन् तर `UNIQUE` constraint सही तरीकाले डुप्लिकेट अस्वीकार गर्दछ)।

केवल एप्लिकेशन कोडमा अखण्डताको लागि निर्भर हुनु जोखिमपूर्ण छ; constraints गारन्टी प्रदान गर्दछन्।

डोमेन/व्यावसायिक नियमहरू (वैध दायरा, अनुमत मानहरू, तार्किक स्थिरता) लागू गर्नको लागि **`CHECK` constraints** बुझ्न पनि मूल्यवान छ सीधा स्कीमामा।

डाटा अखण्डता विश्वसनीय एप्लिकेशनहरूको लागि महत्त्वपूर्ण भएको र constraints बगहरू, race conditions, र असंगत डाटा विरुद्ध सुरक्षा प्रदान गर्दछन् जो एप्लिकेशन कोड एकै लयमा सक्दैन भएकोले, constraints बुझ्न — प्रकारहरू, तिनको अखण्डता गारन्टीहरू, र डाटाबेस-स्तरीय लागूकरणको महत्त्व — मजबुत डाटाबेसहरू डिजाइन गरनको लागि महत्त्वपूर्ण, मौलिक ज्ञान हो र यो एप्लिकेशन बनाउनको लागि एक मुख्य पहलु हो जसको डाटा सगरहरु र वैध रहन्छ।