Criação de tabelas e alteração de dados

Uma definição de tabela descreve o que cada linha pode conter. Ela não adiciona nenhuma linha. Em uma loja virtual, cada produto precisa de campos separados para seu identificador, nome, preço e quantidade em estoque.

Construa a definição

CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  price NUMERIC(8, 2) NOT NULL,
  in_stock INTEGER DEFAULT 0
);

Leia de fora para dentro. CREATE TABLE products dá nome à nova tabela. Os parênteses contêm suas definições de coluna. Cada linha fornece um nome de coluna, um tipo e as regras dessa coluna, se houver. Vírgulas separam as definições; a última não tem vírgula. O ponto e vírgula encerra a instrução. Depois que ela é executada com sucesso, SELECT * FROM products; retorna zero linhas.

Essa declaração de chave gera identificadores no SQLite. No PostgreSQL, use id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY para gerá-los. A declaração decimal também se comporta de modo diferente nesses sistemas; escolher armazenamento exato faz parte da escolha de um tipo.

Dê a cada informação sua própria coluna

Uma linha de cliente poderia conter id, first_name, last_name, email e signup_date. Reunir “Ana Ruiz, ana@example.com” em um único campo dificulta pesquisar ou verificar o nome e o e-mail separadamente. Nomeie os campos de acordo com seu conteúdo. Nomes curtos em minúsculas unidos por sublinhados, como unit_price, são fáceis de reutilizar.

Evite palavras-chave como nomes: orders funciona, enquanto order sem aspas entra em conflito com a palavra-chave ORDER da SQL. Um nome que contém espaços precisa de aspas duplas, como em "order date", sempre que você o usar. O PostgreSQL converte nomes sem aspas para minúsculas, portanto Products e products sem aspas se referem ao mesmo nome.

Aspas simples têm outra função: delimitam valores de texto como 'Desk lamp'. Aspas duplas identificam nomes. O PostgreSQL lê "Desk lamp" como nome de coluna, não como texto de produto.

Verifique o que foi criado

Uma vírgula final antes de ) causa um erro de sintaxe. Uma vírgula ausente também costuma causar erro, mas o SQLite pode ler várias palavras como um único nome de tipo. CREATE TABLE t (a INTEGER b TEXT); cria uma coluna chamada a, não duas. Inspecione a definição:

• Terminal do SQLite: .schema products exibe a instrução de criação.
• SQL do SQLite: PRAGMA table_info(products); lista colunas e tipos.
• psql do PostgreSQL: \d products mostra colunas, tipos e restrições.

CREATE TABLE IF NOT EXISTS products (...) evita um erro quando o nome já existe. A instrução não compara nem atualiza a definição antiga. Uma tabela sem uma coluna necessária continua assim.

Crie uma cópia pontual

CREATE TABLE cheap_products AS
SELECT name, price FROM products WHERE price < 10;

Isso cria colunas e copia as linhas da consulta. Alterações posteriores nos produtos não atualizam a cópia. No SQLite e no PostgreSQL, a nova tabela não herda a chave primária nem as regras NOT NULL ou CHECK da origem.

CREATE, ALTER e DROP pertencem à linguagem de definição de dados, ou DDL: alteram a estrutura. INSERT, UPDATE e DELETE pertencem à linguagem de manipulação de dados, ou DML: alteram linhas. SELECT lê dados; os livros divergem sobre incluí-la na DML ou dar às consultas uma família própria.

Escolha um tipo conforme a função que o valor deve cumprir. Uma quantidade deve permitir operações aritméticas. Um código postal deve preservar seus caracteres, incluindo zeros iniciais. Ambos podem conter dígitos, mas precisam de armazenamento diferente.

Escolha tipos numéricos e de texto

No PostgreSQL, NUMERIC(8, 2) tem oito dígitos no total, dois após a vírgula decimal. Seu maior valor positivo é 999.999,99. Inserir 12,345 armazena 12,35; 1.234.567,00 excede o limite porque precisa de sete dígitos antes da vírgula. DECIMAL é outro nome para essa família de tipos.

O SQLite aceita NUMERIC(8, 2), mas não impõe essa precisão nem essa escala. Ele armazena 19,99 em ponto flutuante e mantém 12,345 sem arredondamento. Armazene 1999 centavos inteiros para um valor exato de 19,99. O ponto flutuante aproxima frações binárias: SELECT 0.1 + 0.2 = 0.3; no SQLite retorna 0. O PostgreSQL trata esses literais decimais sem conversão como valores numéricos exatos; converta-os para DOUBLE PRECISION para ver o resultado aproximado.

Números em texto são ordenados por caracteres: '100', '25', '9' aparecem nessa ordem. Quantidades numéricas precisam de colunas numéricas. O código postal dos EUA '02139' deve ser armazenado como texto; armazená-lo como inteiro faz perder o zero inicial.

O VARCHAR(20) do PostgreSQL rejeita texto com mais de 20 caracteres. Seu CHAR(n) preenche textos mais curtos com espaços até um comprimento fixo. TEXT não tem limite declarado de caracteres. O SQLite trata VARCHAR(n) e CHAR(n) como texto, sem impor o comprimento nem adicionar preenchimento.

Armazene datas e valores sim/não

O PostgreSQL tem DATE, TIME, TIMESTAMP e BOOLEAN. Ele rejeita uma DATE impossível, como '2026-02-30'. O SQLite não tem um tipo de armazenamento dedicado a datas. Use texto ISO como '2026-03-15', cuja ordem dos caracteres corresponde à ordem das datas. O texto no formato dos EUA ordena incorretamente datas de anos diferentes: '12/01/2025' é ordenado depois de '03/15/2026'.

Um registro de data e hora acrescenta uma hora, como em '2026-03-15 14:30:00'. O PostgreSQL usa TRUE e FALSE para booleanos; o SQLite armazena 1 e 0 e aceita essas palavras-chave. O MySQL trata BOOLEAN como um inteiro pequeno; o SQL Server usa BIT.

Saiba o que o sistema impõe

Tabelas comuns do SQLite usam afinidade de tipo, uma preferência de armazenamento. Uma coluna INTEGER converte '5' em 5, mas aceita 'abc' como texto. O PostgreSQL rejeita texto que não pode se tornar um inteiro. O SQLite 3.37.0 e posteriores oferecem suporte a tabelas STRICT, cujos tipos permitidos são INT, INTEGER, REAL, TEXT, BLOB e ANY.

Para pedidos, escolha um id inteiro, e-mail em texto, uma data DATE no PostgreSQL ou em texto ISO no SQLite, NUMERIC(10, 2) no PostgreSQL ou centavos inteiros no SQLite para o total e um indicador booleano ou 0/1 para o pagamento. NULL significa ausente ou desconhecido; não é um tipo nem é igual a zero ou texto vazio. Uma coluna o aceita, a menos que uma regra o proíba.

Uma restrição faz o banco de dados rejeitar dados que violam uma regra declarada. A verificação ocorre quando linhas são inseridas ou atualizadas, independentemente da aplicação que envia a instrução. Regras diferentes protegem partes diferentes de um registro de produto.

Combine regras em uma tabela

Esta definição no SQLite gera a chave e verifica os demais campos. Para o PostgreSQL, substitua a linha da chave por uma chave primária de identidade.

CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  sku TEXT NOT NULL UNIQUE,
  name TEXT NOT NULL,
  price NUMERIC(8, 2) NOT NULL CHECK (price > 0),
  in_stock INTEGER NOT NULL DEFAULT 0 CHECK (in_stock >= 0)
);

NOT NULL exige um valor. UNIQUE impede a repetição de um SKU. CHECK (price > 0) rejeita preços zero ou negativos. A quantidade em estoque tem valor padrão 0 e deve permanecer não negativa. A declaração numérica do SQLite não fornece aritmética decimal exata, portanto use centavos inteiros quando a exatidão for necessária.

Distinga omissão de NULL

Insira uma luminária de mesa com SKU 'LAMP-01', nome 'Desk lamp' e preço 24,99, omitindo o estoque da lista de colunas. A inserção é bem-sucedida e recebe estoque 0. Informar NULL para o estoque não solicita o valor padrão: a inserção falha na restrição NOT NULL.

Uma caneca de café com preço -3,50 falha na verificação de preço. Um segundo produto com SKU 'LAMP-01' falha em UNIQUE, mesmo que seu nome e preço sejam diferentes. Uma caneta sem nome falha em NOT NULL. Leia a regra ou coluna indicada no erro e corrija a entrada.

Texto vazio é um valor real. name TEXT NOT NULL aceita '' no SQLite e no PostgreSQL. Adicione CHECK (name <> '') para rejeitá-lo. O Oracle trata texto vazio como NULL, portanto a mesma entrada está sujeita a uma regra diferente nesse sistema.

Verifique combinações e valores ausentes

Uma regra de coluna vem após seu tipo. Uma regra de tabela é um item separado dentro da definição da tabela e pode comparar colunas:

CHECK (end_date >= start_date),
UNIQUE (order_id, product_id)

A primeira rejeita uma data final anterior à data inicial. A segunda rejeita um par repetido: um produto pode ocorrer em pedidos diferentes, mas não pode aparecer duas vezes no mesmo pedido. Uma tabela pode ter várias restrições de unicidade.

Uma verificação rejeita uma linha quando sua condição é falsa. Se o preço for NULL, price > 0 é desconhecido, portanto a linha passa pela verificação. Por isso, o preço do produto também precisa de NOT NULL. PostgreSQL, SQLite e MySQL normalmente permitem vários valores NULL sob UNIQUE; o SQL Server permite um em uma restrição de unicidade de uma coluna. O PostgreSQL 15 e posteriores oferecem UNIQUE NULLS NOT DISTINCT quando valores ausentes também devem entrar em conflito. Versões do MySQL anteriores à 8.0.16 ignoravam regras CHECK.

Dê à regra um nome útil com CONSTRAINT price_positive CHECK (price > 0). O nome ajuda a identificá-la em um erro e a removê-la depois. Uma restrição verifica exatamente sua expressão: CHECK (email LIKE '%@%') detecta a ausência de arroba, mas não detecta um erro de digitação em um endereço que, de resto, corresponde ao padrão.

Uma chave primária identifica uma linha de forma confiável. Ela pode ser uma coluna ou uma combinação, mas uma tabela tem no máximo uma chave primária. A chave deve ser única e estar presente, para que outras instruções possam identificar uma linha sem depender de sua descrição.

Escolha um identificador estável

Uma chave natural é um identificador existente no mundo real, como o ISBN de um livro. Uma chave substituta é um identificador artificial, muitas vezes um inteiro gerado. O e-mail de um cliente pode mudar; um identificador de cliente gerado pode permanecer o mesmo quando isso acontece.

Uma chave composta identifica uma combinação:

PRIMARY KEY (order_id, product_id)

Um pedido pode conter vários produtos, e um produto pode ocorrer em vários pedidos. O par identifica um item do pedido. Nenhuma das colunas precisa ser única por si só.

PostgreSQL, MySQL e SQL Server exigem que chaves primárias não estejam ausentes. Tabelas comuns do SQLite mantêm uma exceção histórica: uma chave primária diferente de INTEGER PRIMARY KEY pode conter NULL. Use code TEXT PRIMARY KEY NOT NULL para uma chave de texto. As tabelas STRICT do SQLite também eliminam essa possibilidade.

Deixe o banco de dados gerar o número

Omita id da lista de colunas da inserção para solicitar um valor gerado. No PostgreSQL, INTEGER PRIMARY KEY sozinho não o gera. Código mais antigo do PostgreSQL costuma usar SERIAL.

No SQLite, INTEGER PRIMARY KEY é um apelido para o número interno da linha. Comece com os identificadores gerados 1, 2 e 3 e exclua o 3. O próximo identificador gerado normalmente é 3 novamente, um acima do máximo atual. Com INTEGER PRIMARY KEY AUTOINCREMENT, é 4: um número pertencente a uma linha confirmada não é reutilizado. Um número de uma inserção desfeita ainda pode ser reutilizado. Essa garantia mais forte exige trabalho adicional, portanto escolha-a quando o requisito de não reutilização for relevante.

Leia identificadores sem tratá-los como contagens

Lacunas são normais. Exclusões as deixam, e o PostgreSQL não devolve números de sequência após inserções que falharam ou foram desfeitas. Use COUNT(*) para contar linhas e um registro de data e hora para a hora de um evento. O maior identificador não responde de forma confiável a nenhuma das duas perguntas.

A forma GENERATED ALWAYS do PostgreSQL normalmente rejeita um identificador explícito como 50. GENERATED BY DEFAULT e SERIAL aceitam valores explícitos, mas fornecer 50 não faz o gerador avançar além de 50. Um valor gerado posteriormente pode entrar em conflito com ele.

Para usar a chave de uma nova linha em uma linha relacionada, recupere-a:

INSERT INTO customers (first_name, last_name, email)
VALUES ('Dev', 'Patel', 'dev@example.com')
RETURNING id;

RETURNING funciona no PostgreSQL e no SQLite 3.35.0 e posteriores. O SQLite também oferece last_insert_rowid(), o MySQL oferece LAST_INSERT_ID() e o SQL Server usa OUTPUT. Leia o resultado da inserção em vez de adivinhar o próximo identificador.

O customer_id de um pedido deve apontar para um cliente existente. Uma chave estrangeira faz o banco de dados verificar esse vínculo. A tabela que contém a referência é a filha; a tabela para a qual ela aponta é a pai.

Declare e aplique o vínculo

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL REFERENCES customers(id)
);

Aqui, customers deve existir primeiro, e seu id deve ser uma chave primária ou única. Use tipos correspondentes nos dois lados. A forma de tabela, FOREIGN KEY (customer_id) REFERENCES customers(id), declara o mesmo vínculo separadamente da coluna.

Com a aplicação das restrições ativada, um pedido para o cliente 99 falha quando não existe um cliente 99. Atualizar um pedido para esse cliente inexistente também falha. Uma chave estrangeira que aceita valores ausentes pode conter NULL, significando que não há linha vinculada; NOT NULL torna o vínculo obrigatório.

No SQLite, execute PRAGMA foreign_keys = ON; em cada nova conexão antes de iniciar uma transação. Alterar essa configuração dentro de uma transação não tem efeito. PostgreSQL e SQL Server aplicam normalmente as restrições de chave estrangeira, assim como o mecanismo padrão InnoDB do MySQL.

Preveja a exclusão de uma linha pai

Use os clientes 1, Ana, e 2, Ben. Os pedidos 101 e 102 pertencem a Ana; 103 pertence a Ben. Considere a exclusão do cliente 1 sob diferentes declarações:

SET NULL exige uma coluna que aceite valores ausentes. SET DEFAULT ainda precisa satisfazer a chave estrangeira: um valor padrão não ausente deve identificar uma linha pai existente. Um valor padrão NULL funciona quando vínculos ausentes são permitidos.

Escolha de acordo com o significado dos dados. Itens de pedido frequentemente pertencem inteiramente ao pedido, portanto a propagação em cascata pode ser adequada. Pedidos que precisam ser mantidos exigem uma ação de bloqueio quando alguém tenta remover seu cliente. Um vínculo opcional com fornecedor pode receber NULL. Aplicar ações em cascata em toda parte permite que uma exclusão remova mais registros do que o nome de sua tabela sugere.

Trabalhe na ordem das dependências

Crie as tabelas pai antes das filhas e insira linhas pai antes das linhas que fazem referência a elas. Ao remover dados ou tabelas relacionados, trabalhe das tabelas filhas para as pai. Uma ação ON UPDATE oferece as mesmas opções quando a chave da tabela pai muda; ON UPDATE CASCADE copia a nova chave para as linhas filhas.

RESTRICT verifica imediatamente. NO ACTION, o padrão, pode esperar até o fim da instrução ou até o fim da transação no caso de uma restrição adiável. Ambos bloqueiam uma exclusão comum que deixaria referências sem correspondência. Mantenha identificadores gerados estáveis para que alterar os dados de um cliente não exija alterar todas as referências a ele.

INSERT adiciona linhas a uma tabela existente. Sua lista de colunas é o mapa entre os valores que você fornece e os campos que os recebem. Escreva o mapa explicitamente para que uma alteração posterior na tabela não mude silenciosamente o significado da entrada.

Associe valores pela posição

INSERT INTO products (sku, name, price, in_stock)
VALUES ('LAMP-01', 'Desk lamp', 24.99, 12);

Leia os pares em ordem: SKU recebe 'LAMP-01', nome recebe 'Desk lamp', preço recebe 24,99 e estoque recebe 12. Deve haver quatro valores para essas quatro colunas. Uma divergência, como dois valores para três colunas, causa uma falha.

Sem a lista, os valores seguem a ordem declarada das colunas da tabela. O SQLite exige que todas as colunas recebam valores; o PostgreSQL permite menos valores e atribui valores padrão às colunas finais. Uma lista explícita evita depender de qualquer um desses comportamentos. Ela também permite colocar as colunas em uma ordem clara para a entrada.

Um par trocado pode ser pior que um erro de sintaxe. Fornecer 9,99 como nome e 'Desk lamp' como preço faz o PostgreSQL rejeitar o preço não numérico. A afinidade de tipo comum do SQLite pode armazenar o texto “9.99” como nome e o texto “Desk lamp” como preço sem erro. Leia a linha inserida com SELECT para verificar a associação.

Escreva valores literais corretamente

O apóstrofo duplicado armazena um apóstrofo. Números não têm símbolo de moeda nem separador de milhares; uma vírgula separa valores, portanto uma vírgula dentro de um valor sem aspas altera a quantidade de valores. 'NULL' é o texto de quatro letras “NULL”, não um valor ausente.

Deixe os campos omitidos serem preenchidos

Uma coluna omitida recebe seu valor padrão ou NULL se não tiver um. Uma chave gerada recebe um valor gerado. Esse último comportamento depende da declaração: INTEGER PRIMARY KEY do SQLite gera identificadores; o PostgreSQL exige uma declaração de identidade para isso. Uma chave primária inteira simples no PostgreSQL, quando omitida em uma inserção, causa uma falha porque seu valor seria NULL.

PostgreSQL, MySQL e SQL Server permitem DEFAULT como marcador de valor. O SQLite não o aceita dentro de uma lista VALUES; nesse caso, omita a coluna. Um NULL explícito nunca solicita o valor padrão.

Adicione várias linhas juntas

INSERT INTO customers (first_name, last_name, email) VALUES
  ('Ana', 'Ruiz', 'ana@example.com'),
  ('Ben', 'Okafor', 'ben@example.com'),
  ('Chloe', 'Nguyen', 'chloe@example.com');

Em uma tabela vazia cuja chave gerada começa em 1, elas recebem os identificadores 1, 2 e 3. Sob o tratamento comum de restrições, a instrução de várias linhas é bem-sucedida ou falha por inteiro. Se uma linha violar uma regra, nenhuma das linhas dessa instrução será inserida.

Um erro UNIQUE indica uma chave ou valor duplicado; NOT NULL indica dados ausentes; CHECK indica uma condição que falhou; e um erro de chave estrangeira indica um vínculo inválido. Corrija o valor ou sua associação pretendida antes de tentar novamente.

As linhas não precisam ser digitadas uma por vez. Uma consulta pode fornecer as linhas para uma inserção, e uma regra de conflito pode determinar o que acontece quando um valor único já existe. Ambos os recursos dependem da correspondência precisa com os dados pretendidos.

Copie o resultado de uma consulta

INSERT INTO archived_orders (id, customer_id, order_date, total)
SELECT id, customer_id, order_date, total
FROM orders
WHERE order_date < '2026-01-01';

Não há cláusula VALUES: a consulta fornece os valores. Associe as colunas selecionadas à lista de destino pela posição. A tabela de destino já deve existir, e suas regras continuam valendo.

Visualize o SELECT separadamente. Os pedidos 201, 202 e 204 têm as datas 2025-11-03, 2025-12-19 e 2025-10-30 e os totais 45,00, 120,50 e 60,00. Os pedidos 203 e 205 têm datas em 2026. A consulta retorna três linhas que totalizam 225,50, e a inserção copia essas três. Ela também pode copiar zero linhas quando o filtro não encontra nada.

Uma segunda execução tenta copiá-las novamente. Uma chave primária no destino faz a operação falhar em vez de armazenar duplicatas silenciosamente. INSERT ... SELECT é uma operação de cópia; não remove as linhas de origem nem mantém as duas tabelas sincronizadas.

Importações de arquivos frequentemente passam primeiro por uma tabela de preparação. O terminal do SQLite usa .import --csv file.csv staging; o psql usa \copy. Em uma consulta posterior, TRIM(email) remove espaços nas extremidades e NULLIF(TRIM(email), '') transforma um e-mail vazio ou composto de espaços em NULL. As restrições de destino verificam então as linhas limpas.

Leia o resultado de uma gravação

INSERT INTO customers (first_name, last_name, email)
VALUES ('Dev', 'Patel', 'dev@example.com')
RETURNING id;

O resultado fornece o identificador gerado do cliente para uso em uma linha relacionada. PostgreSQL e SQLite 3.35.0 e posteriores oferecem suporte a RETURNING em inserções, atualizações e exclusões. O MySQL usa LAST_INSERT_ID() para um identificador gerado; o SQL Server usa OUTPUT.

Decida como tratar duplicatas

Com stock (sku TEXT PRIMARY KEY, qty INTEGER NOT NULL), suponha que 'LAMP-01' tenha quantidade 12. Uma inserção simples que propõe o mesmo SKU e quantidade 20 falha. No SQLite e no PostgreSQL:

INSERT INTO stock (sku, qty) VALUES ('LAMP-01', 20)
ON CONFLICT (sku) DO UPDATE
SET qty = stock.qty + excluded.qty;

stock.qty é o valor existente 12. excluded.qty é o valor proposto 20. Essa forma armazena 32, adequada para uma entrega adicional. SET qty = excluded.qty armazena 20, adequado para uma contagem substituta. DO NOTHING mantém 12 e ignora a linha conflitante. Cada variação parte da mesma quantidade original 12.

Uma inserção ou atualização combina a inserção de uma nova linha com a atualização em caso de conflito. O alvo do conflito deve ter uma proteção de unicidade adequada. A família equivalente do MySQL é ON DUPLICATE KEY UPDATE. Um INSERT simples não corrige um cliente existente: cria outra linha ou encontra um erro de unicidade. Use UPDATE para uma linha que você sabe que existe e uma inserção ou atualização quando a linha já puder existir.

UPDATE altera valores em linhas que já existem. Ele nomeia uma tabela, atribui novos valores com SET e depois escolhe as linhas-alvo com WHERE. As restrições da tabela verificam os valores resultantes.

Defina um ou vários campos

UPDATE products
SET price = 22.50, in_stock = 30
WHERE id = 3;

O produto com chave 3 recebe ambos os valores; as outras linhas mantêm os seus. As atribuições usam vírgulas. Escrever SET price = 22.50 AND in_stock = 30 não significa duas atribuições. O PostgreSQL rejeita a instrução; o SQLite trata o lado direito como uma expressão booleana e pode armazenar 0 ou 1 no preço.

A ausência de WHERE é válida em SQL e aplica a instrução a todas as linhas. UPDATE products SET price = 0; define o preço de todos os produtos como zero se as regras da tabela permitirem. Uma visualização prévia com a condição pretendida mostra se o alvo é uma linha, várias linhas ou nenhuma.

Calcule a partir do valor armazenado

UPDATE products
SET price = price * 1.10;

Um preço de 20,00 passa a 22,00 após um aumento de 10%. Um preço de 19,99 produz um resultado não arredondado de 21,989. O PostgreSQL armazena 21,99 em uma coluna NUMERIC(8, 2). O SQLite não impõe a escala, portanto SET price = ROUND(price * 1.10, 2) solicita duas casas decimais. Para armazenar dinheiro exatamente no SQLite, mantenha centavos inteiros e decida explicitamente como arredondá-los.

A expressão deve incluir o valor antigo quando a alteração é relativa. SET in_stock = in_stock - 1 remove uma unidade; SET in_stock = 1 substitui a contagem por um.

No SQLite e no PostgreSQL, todas as expressões à direita leem a linha antes da atualização. UPDATE t SET a = b, b = a; troca os valores de uma linha de 1 e 2 para 2 e 1. Uma atualização de tabela única no MySQL avalia as atribuições da esquerda para a direita, portanto a mesma forma define ambos como 2. Não transfira essa suposição entre sistemas.

Considere as regras e os valores ausentes

Use SET phone = NULL para apagar um campo de telefone. Para encontrar valores de telefone ausentes, use WHERE phone IS NULL. Uma igualdade com NULL não os encontra.

Considere os preços 12,00, 3,00 e 8,50 protegidos por CHECK (price > 0). Subtrair 5 de cada preço tornaria o segundo -2,00. No tratamento comum de restrições, essa falha desfaz toda a instrução, portanto até os preços que seriam válidos permanecem inalterados.

Uma atualização de chave primária também precisa satisfazer as chaves estrangeiras relacionadas. Uma alteração de chave bloqueada falha enquanto linhas filhas apontam para a chave antiga; ON UPDATE CASCADE transfere o novo valor para elas. Manter identificadores gerados estáveis evita esse trabalho adicional quando detalhes descritivos mudam.

Interprete a quantidade de linhas afetadas

O psql informa um resultado como UPDATE 3; a função changes() do SQLite informa a contagem da última instrução de alteração. Ambos incluem linhas correspondentes e atualizadas mesmo quando o valor atribuído é igual ao antigo. Uma contagem de três não garante três valores visivelmente diferentes. Compare a contagem com a visualização prévia e inspecione os campos relevantes depois, ou use RETURNING para ver diretamente as linhas afetadas.

DELETE remove linhas inteiras. Ele deixa a tabela pronta para armazenar linhas novamente. Para apagar um campo, use UPDATE ... SET column = NULL; DELETE email FROM customers não é SQL válida.

Acompanhe uma exclusão filtrada

A loja tem estes pedidos:

DELETE FROM orders
WHERE status = 'cancelled'
  AND order_date < '2026-01-01';

O pedido 201 atende aos dois testes, assim como o 204. O pedido 203 está cancelado, mas é recente demais; o 202 é antigo o suficiente, mas foi enviado. A instrução remove duas linhas e mantém 202, 203 e 205. DELETE FROM orders; sem a condição removeria todas as cinco.

Use dados relacionados para escolher linhas

DELETE FROM order_items
WHERE order_id IN (
  SELECT id FROM orders WHERE status = 'cancelled'
);

A consulta interna produz os identificadores dos pedidos cancelados. IN verifica o order_id de cada item em relação a essa lista. Execute a consulta interna separadamente para inspecionar as chaves e depois visualize as linhas de itens com a mesma condição.

As chaves estrangeiras também afetam a exclusão. Uma linha pai com linhas filhas que fazem referência a ela pode ser protegida por NO ACTION ou RESTRICT; uma ação em cascata remove as filhas; SET NULL mantém as filhas, mas apaga o vínculo. Verifique essas ações ao avaliar o efeito da exclusão de uma linha pai, pois a tabela indicada diretamente pode não ser a única alterada.

Escolha o que deve permanecer

PostgreSQL, MySQL, SQL Server e Oracle oferecem suporte a TRUNCATE; o SQLite não. Suas regras de transação e dependência variam conforme o banco de dados. Uma instrução que parece ser uma operação rápida para esvaziar uma tabela ainda precisa respeitar essas regras.

Mantenha o histórico com uma exclusão lógica

UPDATE customers
SET deleted_at = '2026-03-15'
WHERE id = 7;

Uma exclusão lógica marca a linha sem removê-la. Ela pode preservar o histórico e permitir a restauração ao apagar a marca. Consultas de clientes ativos devem incluir WHERE deleted_at IS NULL; caso contrário, os clientes marcados ainda aparecem. Marcar dados não os apaga.

Uma exclusão confirmada não pode ser desfeita por um ROLLBACK posterior. A restauração exige uma cópia salva ou um backup. Dentro de uma transação aberta, o rollback ainda pode restaurar linhas excluídas. Verifique os identificadores selecionados e a contagem de linhas afetadas antes de tornar o resultado permanente.

Escolher linhas costuma ser a parte mais difícil de uma alteração. O mesmo filtro que é inofensivo em uma consulta pode excluir ou atualizar dados demais quando reutilizado em uma gravação. Transforme a regra pretendida em uma condição e depois inspecione o que ela realmente encontra.

Visualize a condição exata

SELECT id, status, order_date FROM orders
WHERE status = 'cancelled'
  AND order_date < '2026-01-01';

Essa visualização retorna os pedidos 201 e 204 no exemplo da loja com cinco pedidos. Reutilize exatamente essa condição na exclusão. Reescrevê-la ao mudar o comando cria uma nova seleção que não foi verificada.

Para uma linha específica, use sua chave primária: WHERE id = 42 corresponde a no máximo uma linha. Um nome descritivo como 'Desk lamp' pode ser compartilhado por vários produtos.

Agrupe alternativas explicitamente

AND tem precedência sobre OR. Compare:

WHERE status = 'cancelled'
   OR status = 'expired' AND order_date < '2026-01-01'

com:

WHERE (status = 'cancelled' OR status = 'expired')
  AND order_date < '2026-01-01'

A primeira aceita todos os pedidos cancelados, independentemente da data, além dos pedidos expirados antes de 2026. Ela corresponde a 201, 203 e 204. A segunda aplica o teste de data aos dois status e corresponde a 201 e 204. O pedido 203 revela a diferença porque foi cancelado em 2026.

Inclua valores ausentes deliberadamente

WHERE customer_id = NULL não corresponde a nenhuma linha. Valores ausentes exigem IS NULL ou IS NOT NULL. Um teste negativo também tem uma lacuna: status <> 'shipped' não inclui um status ausente, porque sua comparação é desconhecida.

Se um status ausente fizer parte do grupo pretendido, escreva:

WHERE status <> 'shipped' OR status IS NULL

Ao adicionar outra condição, agrupe toda essa alternativa entre parênteses para que ambos os ramos atendam a essa condição.

A busca por padrões pode alcançar valores além da descrição pretendida. LIKE '%lamp%' corresponde a “Desk lamp” e “Clamp”. O LIKE padrão do SQLite também ignora a diferença entre maiúsculas e minúsculas nas letras inglesas, portanto encontra “Lamp shade”. Um padrão é útil para encontrar possíveis correspondências, mas inspecione-as antes de alterá-las.

Escolha uma comparação de lista para uma lista

UPDATE orders SET status = 'on hold'
WHERE customer_id IN (
  SELECT id FROM customers WHERE state = 'CA'
);

A subconsulta pode fornecer vários identificadores de clientes; IN verifica se o valor pertence à lista. Substituir IN por = solicita um único resultado escalar. O PostgreSQL rejeita várias linhas nesse caso, enquanto o SQLite usa silenciosamente a primeira linha retornada e deixa outros clientes de fora.

Após a alteração, compare a contagem de linhas afetadas com a visualização prévia. PostgreSQL e SQLite também permitem acrescentar RETURNING * para mostrar as linhas afetadas. Para uma gravação arriscada, inicie uma transação antes de alterar os dados, inspecione o resultado e escolha COMMIT ou ROLLBACK.

Uma transação agrupa instruções relacionadas em uma unidade de trabalho. Você decide manter suas alterações juntas com COMMIT ou desfazê-las juntas com ROLLBACK. A propriedade de tudo ou nada é chamada de atomicidade, o A de ACID.

Mantenha os dois lados de uma transferência

A conta de Maya, ID 1, tem 500,00 reais. A conta de Leo, ID 2, tem 120,00 reais. Transferir 75,00 reais exige duas alterações:

BEGIN;
UPDATE accounts SET balance = balance - 75.00 WHERE id = 1;
UPDATE accounts SET balance = balance + 75.00 WHERE id = 2;
SELECT id, balance FROM accounts WHERE id IN (1, 2);
COMMIT;

A primeira atualização deixa Maya com 425,00 reais. A segunda deixa Leo com 195,00 reais. A verificação mostra ambos os saldos antes da confirmação, e o total permanece em 620,00 reais. Para esses saldos decimais exatos, use NUMERIC no PostgreSQL; no SQLite, uma versão com valores monetários exatos armazena 50.000 e 12.000 centavos e transfere 7500 centavos.

Sem uma transação explícita no modo de confirmação automática, a primeira atualização poderia se tornar permanente antes da execução da segunda. Uma falha entre elas manteria a retirada sem o depósito. Uma transação permite uma única decisão final para manter ou desfazer as duas atualizações. Se uma instrução falhar, trate o erro antes de decidir que a transferência está concluída.

Entenda o limite padrão

Na confirmação automática do banco de dados, cada instrução independente bem-sucedida é confirmada como sua própria transação. Esse é o comportamento inicial habitual do SQLite, PostgreSQL, MySQL e SQL Server. Uma biblioteca de programação ou cliente pode escolher configurações diferentes e iniciar uma transação para você.

BEGIN; inicia uma transação explícita no SQLite e no PostgreSQL. SQLite e SQL Server também usam BEGIN TRANSACTION; PostgreSQL e MySQL aceitam START TRANSACTION. O Oracle inicia uma transação com uma alteração de dados e normalmente espera por COMMIT em ferramentas como o SQL*Plus, a menos que a confirmação automática esteja ativada.

COMMIT encerra a transação e mantém suas alterações. ROLLBACK encerra a transação e desfaz suas alterações não confirmadas. Um rollback posterior não pode desfazer uma confirmação anterior.

Inspecione e desfaça

BEGIN;
DELETE FROM orders;
SELECT * FROM orders;
ROLLBACK;

Sua conexão vê uma tabela vazia no SELECT e depois vê os cinco pedidos novamente após o rollback. O resultado vazio era real dentro da transação, mas ainda não era permanente. Outras conexões normalmente não veem as alterações não confirmadas.

Uma transação só pode proteger contra uma seleção errada de linhas se você inspecionar o resultado e escolher desfazê-lo. A SQL pode atualizar uma linha não pretendida com sucesso: nenhuma regra do banco de dados sabe qual conta você pretendia indicar. Compare identificadores, valores e contagens retornados com o resultado pretendido antes de confirmar.

Mantenha as transações curtas e encerre-as. Transações abertas podem manter bloqueios que fazem outras conexões esperar; o SQLite permite apenas uma conexão de escrita por vez. Fechar uma conexão com uma transação inacabada desfaz suas alterações pendentes. Quando uma biblioteca inicia uma transação automaticamente, o programa precisa chamar seu método de confirmação para manter o trabalho.

Uma instrução que falha não tem o mesmo efeito em todos os bancos de dados. Você precisa saber o que ainda está pendente antes de decidir como se recuperar. Um ponto de salvamento pode oferecer um ponto intermediário ao qual retornar dentro de uma transação aberta.

Acompanhe um erro

Após a transferência, Maya tem 425,00 reais e Leo tem 195,00 reais. A tabela tem CHECK (balance >= 0). Inicie uma transação e subtraia 30,00 reais de Maya: seu saldo pendente é 395,00 reais. Depois, tente subtrair 300,00 reais de Leo. Isso tornaria seu saldo -105,00 reais, portanto a segunda instrução falha.

No SQLite, confirmar nesse momento manteria apenas a dedução de Maya. No PostgreSQL, COMMIT em uma transação em estado de falha a encerra com um rollback. Uma rotina clara de recuperação é executar ROLLBACK, corrigir a causa e executar novamente as instruções relacionadas. Os dois saldos retornam então a 425,00 e 195,00 reais antes da tentativa corrigida.

Desfaça uma parte posterior com um ponto de salvamento

BEGIN;
UPDATE accounts SET balance = balance + 10 WHERE id = 1;
SAVEPOINT after_first;
UPDATE accounts SET balance = balance + 10 WHERE id = 2;
ROLLBACK TO after_first;
COMMIT;

O ponto de salvamento vem após o aumento de Maya. ROLLBACK TO desfaz o aumento posterior de Leo, mas preserva o de Maya. Os saldos finais são 435,00 e 195,00 reais. Ele não encerra a transação externa; COMMIT faz isso.

RELEASE after_first remove o ponto de salvamento sem desfazer as alterações feitas depois dele. Não é uma confirmação permanente independente dentro da transação externa. O PostgreSQL também permite que ROLLBACK TO um ponto de salvamento estabelecido antes de um erro limpe o estado de falha e continue a partir desse ponto.

Verifique se alterações de estrutura podem ser desfeitas

SQLite e PostgreSQL permitem CREATE TABLE, ALTER TABLE e DROP TABLE dentro de transações. Por exemplo, BEGIN; DROP TABLE orders; ROLLBACK; restaura a tabela e suas linhas.

Instruções DDL comuns em tabelas permanentes no MySQL e no Oracle causam confirmações implícitas. Um CREATE TABLE, ALTER TABLE, DROP TABLE ou TRUNCATE TABLE pode confirmar alterações pendentes anteriores além de executar sua própria operação estrutural. Um rollback posterior não pode desfazer esse trabalho anterior. Não suponha que colocar uma transação em torno de um script faça todos os dialetos de banco de dados se comportarem da mesma maneira.

Para uma alteração arriscada de dados, inicie a transação, execute a gravação, inspecione seus valores e sua contagem e então confirme ou desfaça. Por exemplo, inspecione os preços de iluminação após UPDATE products SET price = ROUND(price * 1.10, 2) WHERE category = 'lighting';. Tome a decisão prontamente para que a transação não mantenha outros trabalhos em espera.

ALTER TABLE altera a estrutura de uma tabela existente preservando suas linhas. UPDATE altera os valores contidos nessas linhas. Adicionar um campo de desconto exige ALTER TABLE; aumentar os descontos já armazenados exige UPDATE.

Adicione e renomeie campos

ALTER TABLE customers ADD COLUMN phone TEXT;
ALTER TABLE customers RENAME COLUMN phone TO mobile;
ALTER TABLE customers RENAME TO clients;

SQLite e PostgreSQL compartilham essas formas. Uma nova coluna atribui às linhas existentes seu valor padrão ou NULL quando não há um. ADD COLUMN active INTEGER NOT NULL DEFAULT 1 atribui a cada linha atual o valor 1 em active. Adicionar email TEXT NOT NULL sem valor padrão falha em uma tabela com dados porque as linhas existentes não teriam um valor obrigatório.

O SQLite oferece suporte a RENAME COLUMN a partir da versão 3.25.0 e a DROP COLUMN a partir da 3.35.0. Ao renomear, atualize o código de aplicações e as consultas salvas que fazem referência ao nome antigo. A SQL fora do banco de dados não pode descobrir o novo nome automaticamente.

Preencha os dados antes de exigi-los

No PostgreSQL, adicione uma coluna que aceite valores ausentes, preencha as linhas existentes com valores adequados e só então torne-a obrigatória:

ALTER TABLE customers ADD COLUMN email TEXT;
UPDATE customers SET email = 'unknown@example.com'
WHERE email IS NULL;
ALTER TABLE customers ALTER COLUMN email SET NOT NULL;

Isso ilustra o preenchimento de um campo obrigatório; não declara o e-mail como único. Uma coluna real de e-mail único precisa de valores válidos e distintos. SET NOT NULL falha se ainda houver valores ausentes. O PostgreSQL também permite alterar um tipo com ALTER COLUMN price TYPE NUMERIC(10, 2), definir um valor padrão e adicionar uma verificação nomeada. As linhas existentes devem satisfazer uma regra recém-adicionada.

Remova um campo ou reconstrua uma tabela

ALTER TABLE customers DROP COLUMN mobile; remove o campo e todos os seus valores armazenados. Dependências podem bloquear a operação. O SQLite rejeita a remoção de uma coluna de chave primária, única, indexada ou de chave estrangeira, ou de uma coluna usada por outro objeto do esquema. O PostgreSQL pode remover objetos dependentes com CASCADE, incluindo uma visão que usa a coluna.

O SQLite não pode alterar o tipo de uma coluna existente nem adicionar restrições de chave primária, unicidade, chave estrangeira ou verificação a colunas existentes com um ALTER simples. A versão 3.53.0 adiciona ALTER COLUMN ... SET NOT NULL e DROP NOT NULL, não a edição geral de restrições. Uma coluna recém-adicionada pode ter uma verificação ou referência permitida, mas não pode ter PRIMARY KEY ou UNIQUE; com chaves estrangeiras ativadas, uma referência adicionada precisa de um valor padrão NULL.

Para uma alteração mais ampla no SQLite:

1. Registre os índices, gatilhos e visões que precisam ser recriados. Se as chaves estrangeiras estiverem ativadas, desative-as antes da transação.
2. Inicie uma transação e crie uma nova tabela com as regras desejadas.
3. Copie as linhas usando colunas explícitas em INSERT INTO new_products (...) SELECT ... FROM products;.
4. Remova a tabela antiga e renomeie a nova para products.
5. Recrie os objetos dependentes e execute PRAGMA foreign_key_check;. Resolva quaisquer problemas informados antes de confirmar.
6. Confirme e depois restaure a aplicação das restrições de chave estrangeira se ela estava ativada antes.

O MySQL altera definições com MODIFY COLUMN; o SQL Server usa ALTER COLUMN. Converta uma alteração estrutural para a sintaxe aceita pelo banco de dados de destino antes de executá-la.

DROP TABLE remove o recipiente e também seu conteúdo. Após DROP TABLE archived_orders;, consultas não podem ler essa tabela porque ela não existe mais. Suas restrições, índices e gatilhos são removidos com ela.

Escolha o nível de remoção

DROP TABLE IF EXISTS archived_orders; evita um erro se a tabela estiver ausente. Ainda assim, remove uma tabela existente e seus dados. Um script de configuração que remove e recria tabelas é destrutivo quando executado em um banco de dados com registros que você deseja manter.

Respeite os vínculos entre tabelas

Remova as tabelas filhas antes das pai, invertendo a ordem habitual de criação. No PostgreSQL, remover customers enquanto uma chave estrangeira de pedidos depende dela falha. DROP TABLE customers CASCADE; também remove a chave estrangeira dependente e quaisquer visões dependentes. A tabela de pedidos e suas linhas permanecem, mas o relacionamento com o cliente deixa de ser imposto.

Esse CASCADE do PostgreSQL é diferente do ON DELETE CASCADE de uma chave estrangeira. O primeiro remove objetos dependentes do banco de dados durante uma alteração de estrutura. O segundo remove linhas filhas quando uma linha pai é excluída. Saber qual ação está em uso evita uma previsão incorreta sobre os dados restantes.

No SQLite, com a aplicação de restrições de chave estrangeira ativada, remover uma tabela primeiro executa uma exclusão implícita de suas linhas. Linhas filhas que fazem referência a elas podem bloquear a operação. Se o relacionamento declarar ON DELETE CASCADE, essas linhas filhas podem ser excluídas; SET NULL pode apagar seus vínculos. Portanto, uma remoção de tabela exige a mesma atenção às referências que uma exclusão de linhas, além de atenção à estrutura da tabela removida.

Preserve uma forma de recuperação

Antes de remover ou reconstruir uma tabela com dados reais, preserve uma cópia utilizável. Uma cópia interna rápida dos dados é:

CREATE TABLE products_backup AS
SELECT * FROM products;

No SQLite e no PostgreSQL, isso preserva os dados selecionados, mas não as restrições originais. Não serve como uma reconstrução completa da definição da tabela. Uma exportação ou backup do banco de dados mantém dados para recuperação fora da tabela alterada.

SQLite e PostgreSQL também permitem testar uma remoção dentro de uma transação:

BEGIN;
DROP TABLE archived_orders;
ROLLBACK;

O rollback restaura a tabela e suas linhas porque a remoção não foi confirmada. Depois de confirmada, a remoção não pode ser revertida executando ROLLBACK posteriormente. Em bancos de dados com confirmações implícitas de DDL, envolver a remoção em uma sintaxe de transação não oferece essa oportunidade de desfazê-la. Inspecione o banco de dados de destino e as tabelas envolvidas antes de executar um script de reconstrução.