Beperking controleren - Check constraint

Een controlevoorwaarde is een soort integrity in SQL waarin een vereiste dat door elke moet voldoen specificeert rij in een database tabel . De beperking moet een predikaat zijn . Het kan verwijzen naar een enkele kolom of meerdere kolommen van de tabel. Het resultaat van het gezegde kan ofwel TRUE , FALSE of UNKNOWN , afhankelijk van de aanwezigheid van NULL . Als het predikaat resulteert in UNKNOWN , wordt de beperking niet geschonden en kan de rij worden ingevoegd of bijgewerkt in de tabel. Dit is in strijd met predikaten in WHERE clausules in SELECT of UPDATE uitspraken.

In een tabel met producten zou men bijvoorbeeld een controlebeperking kunnen toevoegen zodat de prijs van een product en de hoeveelheid van een product een niet-negatieve waarde is:

 PRICE >= 0

 QUANTITY >= 0

Als deze beperkingen niet aanwezig waren, zou het mogelijk zijn om een ​​negatieve prijs (- $ 30) of hoeveelheid (-3 items) te hebben.

Controlebeperkingen worden gebruikt om de geldigheid van gegevens in een database te waarborgen en om gegevensintegriteit te bieden . Als ze op databaseniveau worden gebruikt, kunnen applicaties die de database gebruiken geen ongeldige gegevens toevoegen of geldige gegevens wijzigen, zodat de gegevens ongeldig worden, zelfs als de toepassing zelf ongeldige gegevens accepteert.

Definitie

Elke controlevoorwaarde moet in de instructie CREATE TABLE or worden gedefinieerd met ALTER TABLE behulp van de syntaxis:

 CREATE TABLE table_name (
    ...,
    CONSTRAINT constraint_name CHECK ( predicate ),
    ...
 )

 ALTER TABLE table_name
    ADD CONSTRAINT constraint_name CHECK ( predicate )

Als de controlevoorwaarde slechts naar een enkele kolom verwijst, is het mogelijk om de beperking op te geven als onderdeel van de kolomdefinitie.

 CREATE TABLE table_name (
    ...
    column_name type CHECK ( predicate ),
    ...
 )

NOT NULL-beperking

Een beperking is functioneel equivalent aan de volgende controlevoorwaarde met een predikaat: NOT NULLIS NOT NULL

 CHECK (column IS NOT NULL)

Sommige relationele databasebeheersystemen kunnen de prestaties optimaliseren wanneer de NOT NULL beperkingssyntaxis wordt gebruikt in tegenstelling tot de CHECK beperkingssyntaxis die hierboven is gegeven.

Algemene beperkingen

De meeste databasebeheersystemen beperken controlebeperkingen tot een enkele rij, met toegang tot constanten en deterministische functies, maar niet tot gegevens in andere tabellen of tot gegevens die onzichtbaar zijn voor de huidige transactie vanwege transactie-isolatie .

Dergelijke beperkingen zijn niet echt beperkingen voor tabelcontrole, maar eerder beperkingen voor rijcontroles . Omdat deze beperkingen over het algemeen alleen worden geverifieerd wanneer een rij direct wordt bijgewerkt (om prestatieredenen) en vaak wordt geïmplementeerd als impliciet INSERT of UPDATE triggers, zouden integriteitsbeperkingen kunnen worden geschonden door indirecte actie als deze beperkingen er niet waren. Bovendien zouden anders geldige wijzigingen aan deze records dan worden voorkomen door de CHECK beperking. Enkele voorbeelden van gevaarlijke beperkingen zijn:

• CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)
• CHECK (dateInserted = CURRENT_DATE)
• CHECK (countItems = RAND())

Door de gebruiker gedefinieerde triggers kunnen worden gebruikt om deze beperkingen te omzeilen. Hoewel vergelijkbaar in implementatie, is het semantisch duidelijk dat triggers alleen worden geactiveerd als de tabel direct wordt gewijzigd, en dat het de verantwoordelijkheid van de ontwerper is om indirecte, belangrijke wijzigingen in andere tabellen af ​​te handelen; beperkingen aan de andere kant zijn bedoeld om "te allen tijde waar te zijn", ongeacht de acties van de gebruiker of het gebrek aan vooruitziendheid van de ontwerper.

Referenties