Met beperkingen op tabellen en kolommen kunt u de gegevenskwaliteit afdwingen. In SQL zijn er twee manieren om beperkingen voor een tabel te maken:inline en niet in lijn .
In dit artikel ga ik deze beperkingen en de voordelen ervan onderzoeken, en ook uitleggen welke ik aanbeveel en waarom.
Wat is een inline beperking?
Een inline beperking is een beperking die u op dezelfde regel als de kolom declareert bij het maken van een tabel.
CREATE TABLE employee ( emp_id NUMBER(10) PRIMARY KEY, first_name VARCHAR2(200), last_name VARCHAR2(200), dept_id NUMBER(10) );
In dit voorbeeld geven de woorden PRIMARY KEY na de emp_id kolom aan dat emp_id de primaire sleutel is.
Daarom hebben we een primaire sleutelbeperking voor deze kolom gemaakt door de trefwoorden toe te voegen. Het concept is hetzelfde, ongeacht het type beperking.
Wat is een beperking buiten de lijn?
Een out-of-line beperking is de beperking die op een aparte regel voor de kolom is gedeclareerd. We voegen het toe aan het einde van de instructie CREATE TABLE.
We hebben bijvoorbeeld het volgende script:
CREATE TABLE employee ( emp_id NUMBER(10), first_name VARCHAR2(200), last_name VARCHAR2(200), dept_id NUMBER(10), CONSTRAINT pk_emp PRIMARY KEY (emp_id) );
Zoals u kunt zien, hebben we de PRIMARY KEY-beperking ingesteld, genaamd pk_emp , naar de emp_id kolom aan het einde van het statement.
Dit concept werkt op dezelfde manier, ongeacht het type beperking.
Laten we nu het verschil analyseren tussen deze twee soorten beperkingen, behalve waar ze zijn gedeclareerd.
Out-of-line beperkingen kunnen namen hebben gespecificeerd
Bij het maken van out-of-line beperkingen, kunnen we een naam specificeren. Hoewel dit misschien tijdverspilling lijkt, kan het nuttig zijn.
Overweeg dit bij een bepaald voorbeeld:
CREATE TABLE employee ( emp_id NUMBER(10), first_name VARCHAR2(200), last_name VARCHAR2(200), dept_id NUMBER(10), CONSTRAINT pk_emp PRIMARY KEY (emp_id), CONSTRAINT fk_emp_deptid FOREIGN KEY (dept_id) REFERENCES department (dept_id), CONSTRAINT ck_emp_lnlen CHECK (LENGTH(last_name) > 3) );
We hebben de volgende namen gespecificeerd voor enkele beperkingen:
- pk_emp
- fk_emp_deptid
- ck_emp_lnlen
Het lijkt misschien dat het gewoon onnodig typen is, maar dat is het niet. We zullen dit nader bekijken.
Dus waarom moeten we een naam toewijzen aan een beperking?
Het hebben van benoemde beperkingen kan in verschillende situaties nuttig zijn. Zonder de naam op te geven, genereert Oracle automatisch een naam voor de beperking die het doet voor alle inline beperkingen. Meestal geeft deze naam geen bruikbare informatie.
Wanneer u fouten krijgt in SQL-instructies, PL/SQL-code of toepassingscode, is het een goed idee om de naam van de beperking te gebruiken en te weten waar deze naar verwijst, of op zijn minst te raden. Namen als pk_emp of ck_emp_lnlen zou meer beschrijvend zijn dan de generieke EMP1290894FH naam.
Ook wordt bij het beoordelen van uitvoeringsplannen vaak de naam van de beperking gebruikt in de uitvoer, wat het gemakkelijker maakt om uit te zoeken hoe het plan wordt uitgevoerd. Vooral als we gevallen hebben die bepalen of een primaire sleutel of een externe sleutel wordt gebruikt.
NIET NULL-beperkingen kunnen alleen inline worden aangegeven
Er is maar één type beperking dat kan worden gedeclareerd als een inline beperking. Dit is de beperking NOT NULL.
Dit betekent dat je het niet als afwijkend kunt declareren.
Voer de volgende code uit:
CREATE TABLE employee ( emp_id NUMBER(10), first_name VARCHAR2(200), last_name VARCHAR2(200) NOT NULL, dept_id NUMBER(10) );
Bij het uitvoeren van de onderstaande code kunnen we echter zien dat deze niet werkt:
CREATE TABLE employee ( emp_id NUMBER(10), first_name VARCHAR2(200), last_name VARCHAR2(200), dept_id NUMBER(10), CONSTRAINT nn_emp_ln NOT NULL (last_name) );
Kortom, voor de NOT NULL-beperkingen moeten we ze inline declareren.
CONTROLEER beperkingen kunnen verwijzen naar meerdere kolommen
Als u een inline-beperking CHECK maakt, kan deze alleen verwijzen naar de kolom waarin deze wordt gemaakt.
Als u echter een CHECK-beperking maakt die niet in overeenstemming is, kan deze naar meerdere kolommen verwijzen.
Maak de werknemer tabel met de CHECK-beperking zoals hieronder weergegeven:
CREATE TABLE employee ( emp_id NUMBER(10), first_name VARCHAR2(200) CHECK (LENGTH(first_name) > 10), last_name VARCHAR2(200), dept_id NUMBER(10) );
Deze beperking laat zien dat de voornaam langer moet zijn dan 10 tekens.
Wat als we echter willen specificeren dat de combinatie van voornaam en achternaam moeten meer dan 10 tekens bevatten?
Om dit te doen, herschrijft u de code als een beperking die niet in lijn is:
CREATE TABLE employee ( emp_id NUMBER(10), first_name VARCHAR2(200),, last_name VARCHAR2(200), dept_id NUMBER(10), CONSTRAINT ck_fullname_len CHECK (LENGTH(first_name || last_name) > 10) );
We kunnen zien dat deze regel alleen kan worden geïmplementeerd met een out-of-line beperking.
Aanbevolen methode
Na beide methoden te hebben geanalyseerd:inline of out-of-line, raad ik aan de out-of-line-beperkingen te gebruiken.
Hier zijn een paar redenen voor.
Ten eerste kunt u een naam opgeven voor uw beperkingen en deze bekijken in foutmeldingen en interne uitvoeringsplannen. Het kan ook helpen bij het in- en uitschakelen van beperkingen.
Ten tweede kunt u met controlebeperkingen verwijzen naar meerdere en enkele kolommen. Het is dus flexibeler als je ze toevoegt als een beperking buiten de lijn.
Ten slotte maakt het gemakkelijker om naar uw CREATE TABLE-syntaxis te kijken en al uw beperkingen op één plek te zien, als u alle beperkingen als buiten de lijn hebt gedeclareerd (behalve NOT NULL die alleen kan worden gedefinieerd als een inline-beperking). Het is vooral belangrijk in de gevallen waarin er grote tabellen zijn met veel beperkingen.
Kortom, u kunt beperkingen creëren met behulp van twee verschillende methoden:inline en out-of-line. Ik raad aan om waar mogelijk de out-of-line-methode te gebruiken, omdat er meer flexibiliteit is, en om de beperkingen een naam te geven, waardoor de analyse van uw uitvoeringsplannen en andere SQL-informatie wordt vereenvoudigd.