Restrições são regras impostas pelo banco de dados nos dados das tabelas — garantindo a integridade dos dados no nível do banco de dados (não apenas no código da aplicação). As principais são: PRIMARY KEY, FOREIGN KEY, UNIQUE, , e .
Restrições são regras impostas pelo banco de dados nos dados das tabelas — garantindo a integridade dos dados no nível do banco de dados (não apenas no código da aplicação). As principais são: PRIMARY KEY, FOREIGN KEY, UNIQUE, , e .
NOT NULLCHECKDEFAULTCREATE TABLE users (
id INT PRIMARY KEY, -- unique + not null identifier
email VARCHAR(255) UNIQUE NOT NULL, -- must be unique AND present
age INT CHECK (age >= 0 AND age <= 120), -- must satisfy a condition
country VARCHAR(2) DEFAULT 'US', -- default value if not provided
role VARCHAR(20) NOT NULL DEFAULT 'user',
manager_id INT REFERENCES users(id) -- FOREIGN KEY (referential integrity)
);
PRIMARY KEY → uniquely identifies a row (unique + not null, indexed)
FOREIGN KEY → references another table's key (referential integrity)
UNIQUE → no duplicate values allowed in this column
NOT NULL → the column must have a value (can't be NULL)
CHECK → the value must satisfy a condition (age >= 0, status IN (...))
DEFAULT → a value used when none is provided on insert
-- ❌ relying only on application code to enforce uniqueness:
-- a race condition or a bug or a different app could insert a duplicate
-- ✅ a UNIQUE constraint guarantees it at the DB level — ALWAYS enforced,
-- regardless of which code or how many apps access the database
email VARCHAR(255) UNIQUE
As restrições do banco de dados são a última linha de defesa para a integridade dos dados — são aplicadas independentemente de qual código insere dados (múltiplas aplicações, scripts, mudanças manuais ou código com bugs), e tratam condições de corrida que verificações no nível da aplicação não capturam.
CHECK (price > 0) -- prices must be positive
CHECK (status IN ('active', 'inactive')) -- only valid statuses
CHECK (end_date > start_date) -- logical consistency
CHECK aplica regras de negócio/domínio diretamente no schema.
As restrições são essenciais para manter a integridade dos dados — garantem que os dados no seu banco de dados satisfaçam regras (unicidade, presença, valores válidos, referências válidas) no nível do banco de dados, o que é fundamental para aplicações confiáveis, então compreendê-las é importante.
Conhecer os tipos de restrição (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT) e o que cada uma aplica é necessário para o design apropriado do schema.
O ponto conceitual mais importante é por que aplicar no nível do banco de dados em vez de apenas no código da aplicação: restrições de banco de dados são a última linha de defesa para a integridade dos dados — sempre são aplicadas independentemente de qual código ou quantas aplicações acessam os dados, capturam bugs que verificações de aplicação podem perder, e crucialmente tratam condições de corrida que validação no nível da aplicação não consegue (por exemplo, duas inserções simultâneas passando por uma verificação de unicidade no nível da aplicação, mas uma restrição UNIQUE rejeitando corretamente o duplicado).
Depender apenas do código da aplicação para integridade é arriscado; restrições fornecem uma garantia.
Compreender restrições CHECK para aplicar regras de domínio/negócio (intervalos válidos, valores permitidos, consistência lógica) diretamente no schema é também valioso.
Como a integridade dos dados é crítica para aplicações confiáveis, e como restrições fornecem garantias no nível do banco de dados que protegem contra bugs, condições de corrida e dados inconsistentes de formas que apenas código da aplicação não consegue, compreender restrições — os tipos, suas garantias de integridade e a importância da aplicação no nível do banco de dados — é conhecimento importante e fundamental para projetar bancos de dados robustos e um aspecto-chave para construir aplicações cujos dados permanecem consistentes e válidos.