Database constraint-ek
NOT NULL, UNIQUE, CHECK és FOREIGN KEY: hogyan védi az adatbázis az invariánsokat akkor is, ha több kliens vagy bug próbál hibás adatot írni?
Röviden
A constraint adatbázis-szintű szabály, amely meghatározza, milyen állapot érvényes. Mivel minden írási útvonalon ugyanaz az adatbázis érvényesíti, erősebb végső védőháló, mint ha ugyanaz a szabály csak egy form komponensben élne.
Mit jelent a database constraint-ek?
A constraint adatbázis-szintű szabály, amely meghatározza, milyen állapot érvényes. Mivel minden írási útvonalon ugyanaz az adatbázis érvényesíti, erősebb végső védőháló, mint ha ugyanaz a szabály csak egy form komponensben élne.
Adat-integritási védőháló
01
NOT NULL
02
UNIQUE
03
CHECK
04
FOREIGN KEY
05
PK
Hogyan működik a gyakorlatban?
NOT NULL kötelező értéket, UNIQUE egyediséget, CHECK logikai feltételt, FOREIGN KEY referenciális integritást ad. Primary key tipikusan egyediség és NOT NULL kombinációja speciális kulcsszereppel.
- Email egyediséghez adatbázis constraint kell, ha valóban invariáns.
- Pozitív árhoz CHECK constraint használható.
- Enum-szerű státusznál CHECK vagy típus segíthet.
- Foreign key meggátolhat nem létező rekordra hivatkozást.
Gyakorlati fejlesztői szemlélet
Validálj felhasználóbarát módon alkalmazási rétegben, de a kritikus invariánst védd DB-ben is. Két párhuzamos request könnyen átcsúszhat az „előbb ellenőrzöm, aztán beszúrom” race conditionön, UNIQUE constraint viszont végső döntést hoz.
Gyakori hibák és félreértések
- Minden szabályt csak frontend form validációban tartani.
- Unique ellenőrzést SELECT-tel megoldani constraint nélkül.
- Constraint hibát generikus 500-ként kiszolgálni mapping nélkül.
Források és szabványok
A technikai részletekhez elsődleges szabványokat és karbantartott hivatalos dokumentációt használok. Frameworkök, böngészők és webes API-k idővel változhatnak, ezért implementálás előtt mindig ellenőrizd az aktuális dokumentációt is.
Kapcsolódó ByBence Academy