sql >> Database teknologi >  >> RDS >> Database

Forskellen mellem inline og out-of-line begrænsninger

Begrænsninger på tabeller og kolonner giver dig mulighed for at håndhæve datakvaliteten. I SQL er der to måder at oprette begrænsninger på en tabel på:inline og ud af linje .

I denne artikel vil jeg udforske disse begrænsninger og de fordele, de har, samt forklare, hvilken jeg anbefaler og hvorfor.

Hvad er en inline-begrænsning?

En indlejret begrænsning er en begrænsning, du erklærer på samme linje som kolonnen, når du opretter en tabel.

CREATE TABLE medarbejder (emp_id NUMBER(10) PRIMARY KEY,first_name VARCHAR2(200),last_name VARCHAR2(200),dept_id NUMBER(10));

I dette eksempel angiver ordene PRIMARY KEY efter kolonnen emp_id, at emp_id er den primære nøgle.

Derfor har vi oprettet en primær nøglebegrænsning på denne kolonne ved at tilføje nøgleordene. Konceptet er det samme uanset begrænsningstypen.

Hvad er en out-of-line-begrænsning?

En out-of-line begrænsning er begrænsningen, der er erklæret på en separat linje for kolonnen. Vi tilføjer det i slutningen af ​​CREATE TABLE-sætningen.

For eksempel har vi følgende script:

CREATE TABLE-medarbejder (emp_id NUMBER(10),first_name VARCHAR2(200),last_name VARCHAR2(200),dept_id NUMBER(10),CONSTRAINT pk_emp PRIMARY KEY (emp_id));

Som du kan se, sætter vi PRIMARY KEY-begrænsningen, kaldet pk_emp , til emp_id-kolonnen i slutningen af ​​sætningen.

Dette koncept fungerer på samme måde uanset begrænsningstypen.

Lad os nu analysere forskellen mellem disse to typer begrænsninger, bortset fra hvor de er deklareret.

Out-of-line begrænsninger kan have navne specificeret

Når vi opretter out-of-line begrænsninger, kan vi angive et navn. Selvom dette kan virke spild af tid, kan det være nyttigt.

Overvej dette på et bestemt eksempel:

CREATE TABLE medarbejder (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_idES) ),CONSTRAINT ck_emp_lnlen CHECK (LENGTH(last_name)> 3));

Vi har angivet følgende navne for nogle få begrænsninger:

  • pk_emp
  • fk_emp_deptid
  • ck_emp_lnlen

Det kan virke som om det bare er unødvendigt at skrive, men det er det ikke. Det vil vi se nærmere på.

Så hvorfor skal vi tildele et navn til en begrænsning?

At have navngivne begrænsninger kan være nyttigt i flere situationer. Uden at angive navnet genererer Oracle automatisk et navn til begrænsningen, som det gør for alle inline begrænsninger. Normalt giver dette navn ingen nyttige oplysninger.

Når du får fejl i SQL-sætninger, PL/SQL-kode eller applikationskode, er det en god idé at bruge begrænsningsnavnet og vide, hvad det refererer til eller i det mindste gætte. Sådanne navne som pk_emp eller ck_emp_lnlen ville være mere beskrivende end den generiske EMP1290894FH navn.

Når man gennemgår eksekveringsplaner, bruges begrænsningsnavnet ofte i outputtet, hvilket gør det nemmere at regne ud, hvordan planen bliver eksekveret. Især når vi har tilfælde, der afgør, om primærnøgle eller fremmednøgle bliver brugt.

IKKE NULL-begrænsninger kan kun erklæres inline

Der er kun én begrænsningstype, der kan erklæres som en inline begrænsning. Dette er NOT NULL-begrænsningen.

Det betyder, at du ikke kan erklære det som out of line.

Udfør følgende kode:

CREATE TABLE medarbejder (emp_id NUMBER(10),first_name VARCHAR2(200),last_name VARCHAR2(200) NOT NULL,dept_id NUMBER(10));

Men når vi kører koden nedenfor, kan vi se, at den ikke virker:

CREATE TABLE medarbejder (emp_id NUMBER(10),first_name VARCHAR2(200),last_name VARCHAR2(200),dept_id NUMBER(10),CONSTRAINT nn_emp_ln NOT NULL (last_name));

For at opsummere det, for NOT NULL-begrænsningerne skal vi erklære dem inline.

TJEK Begrænsninger kan henvise til flere kolonner

Hvis du opretter en CHECK inline-begrænsning, kan den kun henvise til den kolonne, den oprettes på.

Men hvis du opretter en CHECK-begrænsning som ude af linjen, kan den referere til flere kolonner.

Opret medarbejderen tabel med CHECK-begrænsningen som vist nedenfor:

CREATE TABLE medarbejder (emp_id NUMBER(10),first_name VARCHAR2(200) CHECK (LENGTH(first_name)> 10),last_name VARCHAR2(200),dept_id NUMBER(10));

Denne begrænsning viser, at fornavn skal overstige 10 tegn.

Men hvad nu hvis vi ønskede at specificere, at kombinationen fornavn og efternavn skal overstige 10 tegn?

For at gøre dette skal du omskrive koden som en out-of-line begrænsning:

CREATE TABLE medarbejder (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)); 

Vi kan se, at denne regel kun kan implementeres med en out-of-line begrænsning.

Anbefalet metode

Efter at have analyseret begge metoder:inline eller out of line, anbefaler jeg at bruge out-of-line begrænsninger.

Der er et par grunde til dette.

Først kan du angive et navn til dine begrænsninger og se dem i fejlmeddelelser og interne udførelsesplaner. Det kan også hjælpe med at deaktivere og aktivere begrænsninger.

For det andet giver check-begrænsninger dig mulighed for at henvise til flere og enkelte kolonner. Det er således mere fleksibelt, hvis du tilføjer dem som en out-of-line begrænsning.

Endelig, at have alle begrænsninger erklæret som out-line (undtagen NOT NULL, som kun kan defineres som en inline-begrænsning), gør det lettere at se på din CREATE TABLE-syntaks og se alle dine begrænsninger på ét sted. Det er vigtigt, især i de tilfælde, hvor der er store borde med mange begrænsninger.

Afslutningsvis kan du oprette begrænsninger ved hjælp af to forskellige metoder:inline og out of line. Jeg anbefaler at bruge out-of-line metoden, hvor du kan, fordi der er mere fleksibilitet, og at sætte et navn til begrænsningerne, hvilket forenkler analysen af ​​dine eksekveringsplaner og andre SQL-oplysninger.


  1. Forskellig repræsentation af UUID i Java Hibernate og SQL Server

  2. Sådan kontrolleres MySQL-databasestørrelse i Linux

  3. Tilslutning af din ASP.NET-kerneapplikation til en lokal forekomst af SQLServer

  4. Komplet vejledning til at rette SQL-databasefejl 5243