Restrições em tabelas e colunas permitem que você imponha a qualidade dos dados. No SQL, há duas maneiras de criar restrições em uma tabela:inline e fora de linha .
Neste artigo, vou explorar essas restrições e as vantagens que elas têm, além de explicar qual delas eu recomendo e por quê.
O que é uma restrição em linha?
Uma restrição em linha é uma restrição que você declara na mesma linha que a coluna ao criar uma tabela.
CREATE TABLE funcionário (emp_id NUMBER(10) PRIMARY KEY,first_name VARCHAR2(200),last_name VARCHAR2(200),dept_id NUMBER(10));
Neste exemplo, as palavras PRIMARY KEY após a coluna emp_id indicam que emp_id é a chave primária.
Assim, criamos uma restrição de chave primária nesta coluna adicionando as palavras-chave. O conceito é o mesmo independentemente do tipo de restrição.
O que é uma restrição fora de linha?
Uma restrição fora de linha é a restrição declarada em uma linha separada para a coluna. Nós o adicionamos no final da instrução CREATE TABLE.
Por exemplo, temos o seguinte script:
CREATE TABLE funcionário (emp_id NUMBER(10),first_name VARCHAR2(200),last_name VARCHAR2(200),dept_id NUMBER(10),CONSTRAINT pk_emp PRIMARY KEY (emp_id));
Como você pode ver, definimos a restrição PRIMARY KEY, chamada pk_emp , para a coluna emp_id no final da instrução.
Esse conceito funciona da mesma maneira, independentemente do tipo de restrição.
Agora, vamos analisar a diferença entre esses dois tipos de restrições, além de onde elas são declaradas.
Restrições fora de linha podem ter nomes especificados
Ao criar restrições fora de linha, podemos especificar um nome. Embora isso possa parecer uma perda de tempo, pode ser útil.
Considere isso em um exemplo específico:
CREATE TABLE funcionário (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 departamento (dept_id) ),CONSTRAINT ck_emp_lnlen CHECK (LENGTH(last_name)> 3));
Especificamos os seguintes nomes para algumas restrições:
- pk_emp
- fk_emp_deptid
- ck_emp_lnlen
Pode parecer que é apenas uma digitação desnecessária, no entanto, não é. Vamos dar uma olhada mais de perto nisso.
Então, por que precisamos atribuir um nome a uma restrição?
Ter restrições nomeadas pode ser útil em várias situações. Sem especificar o nome, o Oracle gera automaticamente um nome para a restrição que faz para todas as restrições em linha. Normalmente, esse nome não fornece nenhuma informação útil.
Quando você obtém erros em instruções SQL, código PL/SQL ou código do aplicativo, é uma boa ideia usar o nome da restrição e saber a que ela se refere ou pelo menos tentar adivinhar. Nomes como pk_emp ou ck_emp_lnlen seria mais descritivo do que o genérico EMP1290894FH nome.
Além disso, ao revisar os planos de execução, o nome da restrição geralmente é usado na saída, o que torna mais fácil descobrir como o plano está sendo executado. Especialmente, quando temos casos determinando se a chave primária ou chave estrangeira está sendo usada.
As restrições NOT NULL só podem ser declaradas em linha
Há apenas um tipo de restrição que pode ser declarado como uma restrição inline. Esta é a restrição NOT NULL.
Isso significa que você não pode declará-lo como fora de linha.
Execute o seguinte código:
CREATE TABLE funcionário (emp_id NUMBER(10),first_name VARCHAR2(200),last_name VARCHAR2(200) NOT NULL,dept_id NUMBER(10));
Porém, ao executar o código abaixo, podemos ver que ele não funciona:
CREATE TABLE funcionário (emp_id NUMBER(10),first_name VARCHAR2(200),last_name VARCHAR2(200),dept_id NUMBER(10),CONSTRAINT nn_emp_ln NOT NULL (last_name));
Para resumir, para as restrições NOT NULL, devemos declará-las inline.
Restrições de VERIFICAÇÃO podem se referir a várias colunas
Se você criar uma restrição em linha CHECK, ela só poderá se referir à coluna em que está sendo criada.
No entanto, se você criar uma restrição CHECK como fora de linha, ela poderá se referir a várias colunas.
Crie o funcionário tabela com a restrição CHECK como mostrado abaixo:
CREATE TABLE funcionário (emp_id NUMBER(10),first_name VARCHAR2(200) CHECK (LENGTH(first_name)> 10),last_name VARCHAR2(200),dept_id NUMBER(10));
Essa restrição mostra que first_name deve exceder 10 caracteres.
No entanto, e se quisermos especificar que a combinação de nome e sobrenome deve exceder 10 caracteres?
Para fazer isso, reescreva o código como uma restrição fora de linha:
CREATE TABLE funcionário (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));
Podemos ver que esta regra só pode ser implementada com uma restrição fora de linha.
Método recomendado
Tendo analisado os dois métodos:inline ou out of line, recomendo usar as restrições out-of-line.
Existem algumas razões para isso.
Primeiro, você pode especificar um nome para suas restrições e vê-las em mensagens de erro e planos de execução internos. Também pode ajudar a desabilitar e habilitar restrições.
Em segundo lugar, as restrições de verificação permitem que você faça referência a colunas múltiplas e únicas. Assim, é mais flexível se você adicioná-los como uma restrição fora de linha.
Finalmente, ter todas as restrições declaradas como fora de linha (exceto NOT NULL que só pode ser definida como uma restrição inline) torna mais fácil olhar para a sintaxe CREATE TABLE e ver todas as suas restrições em um só lugar. É importante especialmente nos casos em que há tabelas grandes com muitas restrições.
Concluindo, você pode criar restrições usando dois métodos diferentes:inline e out of line. Eu recomendo usar o método out-of-line onde você puder, porque há mais flexibilidade, e definir um nome para as restrições, simplificando assim a análise de seus planos de execução e outras informações SQL.
