Check Constraint i MySQL? Er det mulig?

[terjeelde]

Det kan vi være enige om. Kan selvfølgelig løses ved å bruke "riktig" isolasjonsnivå.

 

Kan selvfølgelig "løses" ved å bruke riktig isolasjonsnivå.

 

Fra spøk til alvor... Dersom man bare sjekker om raden finnes i øyeblikket man setter inn en referanse til den, men ikke bruker foreign constraints, så tror jeg man fort lager ris til egen bak. Det går nok bra i noen tilfeller, men ofte vil det føre til tull og krøll, fordi raden man refererer til fort kan forsvinne i ettertid osv.

 

Det er jo en grunn til at man bruker foreign keys referanser.

[kaffenils]

Det er jo en grunn til at man bruker foreign keys referanser.

 

Selvfølgelig. Nå var det heller ikke foreign key constraint sIDDIs spurte om, men check constraints

[siDDis]

Check constraints er IMO meir viktig for å ha god dataintegritet enn foreign keys, jævla MySQL altså...

[kaffenils]

Check constraints er IMO meir viktig for å ha god dataintegritet enn foreign keys, jævla MySQL altså...

 

Nja, tja... Selvfølgelig er check constraints nyttig, men for min del så bruker jeg 50 foreign key constrains for hver check constraint jeg oppretter, og ville heller valgt å ha foreign key constraints fremfor check constraints hvis jeg måtte velge.

Hva som er viktigst? De er vel like viktige til sitt bruk. Jeg tror allikevel at foreign keys er mye mer brukt, og det er vel kanskje derfor MySql har brukt tid på å legge inn støtte for disse istedet for check constraints. Check constraints er dessuten lettere å "emulere" ved bruk av triggere.

[siDDis]

Eg er vell som SQLite folka meiner det motsatte er derfor dei har lagt til støtte for check constraints før foreign keys der. Å emulere foreign key constraints med triggere er jo ikkje vanskeleg.

[kaffenils]

Eg er vell som SQLite folka meiner det motsatte er derfor dei har lagt til støtte for check constraints før foreign keys der. Å emulere foreign key constraints med triggere er jo ikkje vanskeleg.

 

Vanskelig? Nei, men du trenger bare en trigger for å emulere en check constraint, mens du trenger minimum to triggere for å emulere en foreign key constraint ; en trigger i "parent" tabellen, og en trigger pr tabell som refererer til denne.

 

Jeg mistenker at check constraints er lettere å implementere enn foreign key constraints, og det er vel derfor SQLite utviklerene har valgt støtte for dette

[terjeelde]

Jeg mistenker at check constraints er lettere å implementere enn foreign key constraints, og det er vel derfor SQLite utviklerene har valgt støtte for dette

 

Enig med kaffemannen ang. SQLite.

 

Ikke nødvendigvis enig med noen at dette er lett via triggere.

 

Det er gjerne gjennomførbart, men langt fra trivielt å gjøre på en trygg måte i alle tilfeller.

 

Ta f.eks PostgreSQL sitt default isolation level. En transaksjon vil se rader fra en anen. Med native foreign key references vil PosgreSQL blokke rett transaksjon på rette måten, til den andre transaksjonen er committed.

 

Litt uklart for meg ihvertfall, å se hvor lett det er å implementere lignende oppførsel med triggere.

[kaffenils]

Ikke nødvendigvis enig med noen at dette er lett via triggere.

 

Det er gjerne gjennomførbart, men langt fra trivielt å gjøre på en trygg måte i alle tilfeller.

 

Ta f.eks PostgreSQL sitt default isolation level. En transaksjon vil se rader fra en anen. Med native foreign key references vil PosgreSQL blokke rett transaksjon på rette måten, til den andre transaksjonen er committed.

 

Litt uklart for meg ihvertfall, å se hvor lett det er å implementere lignende oppførsel med triggere.

 

En check constraint er lett å lage med triggere da det eneste du skal gjøre er å validere om verdiene er gyldige, f.eks. at en kolonne Price har verdi > 0. Hvis validering feiler så ruller vi tilbake.

 

Foreign key triggere er mye mer kompliserte. For det første er det innebærer det selvfølgelig flere spørringer, og for det andre må du tenke på problematikken rundt dirty reads og phantom reads. Uten å ha tenkt veldig grundig gjennom det så ser jeg for meg at dette kan løses ved at spørringene i triggeren eksekverer i et REPEATABLE READ

isolasjonsnivå. Da er du garantert at når du har sjekket at en foreign key eksisterer så kan den ikke slettes eller endres før du er ferdig med transaksjonen.

[terjeelde]

En check constraint er lett å lage med triggere da det eneste du skal gjøre er å validere om verdiene er gyldige, f.eks. at en kolonne Price har verdi > 0. Hvis validering feiler så ruller vi tilbake.

 

Du får unnskylde meg... Jeg har ikke fått i meg nok kaffe til å være våken riktig helt enda.

 

Du har jo selvsagt rett.

 

Tenkte på eksempelet fra tidligere i tråden, om å bruke triggers for å sjekke om rander andresteder finnes osv.

[kaffenils]

Kaffe er viktig ser du . Kommer vel frem av nicket mitt.

Har allerede begynt på kopp nr. 3.