Antwoord

Constraints zijn integriteitsbeperkingen die op kolommen of tabellen worden opgelegd voor automatische controle van toegestane waarden. Ze stellen ons in staat om:

• Gegevens te beschermen tegen onjuiste invoer;
• Een deel van de applicatielogica naar de database te verplaatsen (betrouwbaarder en sneller);
• Automatisch voorwaarden te controleren bij invoegen, bijwerken of verwijderen.

Soorten belangrijke constraints:

• PRIMARY KEY — unieke identificatie, voorkomt duplicatie en NULL.
• UNIQUE — voorkomt duplicatie van waarden in één kolom.
• FOREIGN KEY — referentiele integriteit, koppeling met een andere tabel.
• CHECK — controle van een willekeurige expressie.
• NOT NULL — verbod op NULL-waarden in de kolom.

Voorbeeld:

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INT REFERENCES users(id), -- foreign key
  price DECIMAL(10,2) CHECK (price > 0),
  created_at TIMESTAMP NOT NULL
);

Vragensoort met een addertje onder het gras

"Is een unieke sleutel (UNIQUE) automatisch NULL-SAFE, waarbij elk aantal NULL-waarden in de kolom wordt uitgesloten?"

In feite staat een UNIQUE-beperking in de meeste DBMS (zoals PostgreSQL, MySQL) meerdere rijen met een NULL-waarde toe, aangezien NULL wordt beschouwd als "onbekend". Dit leidt vaak tot onopgemerkte duplicatie van lege waarden.

Voorbeeld:

CREATE TABLE test (
  id INT PRIMARY KEY,
  code VARCHAR(10) UNIQUE
);

INSERT INTO test (id, code) VALUES (1, NULL), (2, NULL); -- zal slagen

Voorbeelden van echte fouten door onwetendheid over de nuances van het onderwerp

---

Verhaal

De applicatie stond registratie via e-mail toe, de kolom was UNIQUE, maar NIET NOT NULL - er waren een tiental gebruikers met een NULL-email in de tabel, wat problemen veroorzaakte bij integratie met externe services.

---

Verhaal

In het ticketsysteem was de FOREIGN KEY naar de tabel betalingen vergeten toe te voegen - als gevolg hiervan waren er betalingen die aan geen enkele bestelling waren gekoppeld, wat het moeilijk maakte om terugbetalingen aan gebruikers te doen.

---

Verhaal

**CHECK-constraint voor korting: discount > 0. De randvoorwaarde voor 0 was vergeten. Resultaat: het systeem accepteerde alleen kortingen groter dan 0, terwijl het ontbreken van korting (0) de bedrijfslogica verstoorde.