Felipe Cezar

Posted on Mar 5

A Pegadinha do Auto-Incremento: Como o SERIAL do PostgreSQL se compara a outros SGBDs

#sql

Se você está começando na área de dados ou backend, é quase certeza que você aprendeu a criar tabelas em um banco de dados específico (como o MySQL) e, quando foi tentar rodar o mesmo script em outro banco (como o PostgreSQL), tomou um belo erro de sintaxe na cara.

A maior vítima dessa "salada de frutas" entre os Sistemas Gerenciadores de Banco de Dados (SGBDs) é a famosa coluna de ID automático.

Neste artigo, vamos desmistificar como o PostgreSQL lida com isso através do SERIAL e como essa mesma funcionalidade é escrita nos outros gigantes do mercado.

🐘 O que é o SERIAL no PostgreSQL?

A primeira coisa que você precisa saber e que "buga" a cabeça de muita gente: o SERIAL não é um tipo de dado real. Ele é uma "pseudo-tipagem", um atalho de conveniência que o Postgres criou para facilitar a nossa vida. Quando você define uma coluna como SERIAL, o banco de dados faz três coisas automaticamente por debaixo dos panos:

Cria um objeto gerador de números chamado SEQUENCE.
Define o tipo real da sua coluna como INTEGER.
Adiciona uma restrição DEFAULT na coluna, dizendo que, se você não enviar um ID no seu INSERT, o banco deve puxar o próximo número gerado pela sequência (1, 2, 3...).

Exemplo na prática (PostgreSQL):

CREATE TABLE funcionario (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(255),
    data_admissao DATE
);

🌍 Como o Auto-Incremento funciona em outros Bancos?

O SQL tem um padrão universal (ANSI), mas na hora de criar IDs automáticos, cada fabricante decidiu seguir o seu próprio caminho. Olha só como a mesma tabela acima seria criada nos concorrentes:

1. MySQL e MariaDB (O Clássico)

Se você vem do PHP ou dos tutoriais clássicos de web, esse é o que você conhece. O MySQL usa a palavra-chave explícita AUTO_INCREMENT atrelada ao tipo inteiro.

CREATE TABLE funcionario (
    id INT AUTO_INCREMENT PRIMARY KEY,
    nome VARCHAR(255),
    data_admissao DATE
);

2. SQL Server / T-SQL (O Jeito Microsoft)

A Microsoft resolveu chamar essa funcionalidade de "Identidade". Você usa a palavra IDENTITY e pode até definir onde começa e de quanto em quanto o número pula. Exemplo: IDENTITY(1,1) significa "comece no 1 e pule de 1 em 1".

CREATE TABLE funcionario (
    id INT IDENTITY(1,1) PRIMARY KEY,
    nome VARCHAR(255),
    data_admissao DATE
);

3. Oracle (A Evolução)

O Oracle historicamente dava mais trabalho. Você precisava criar uma SEQUENCE na mão e depois criar uma TRIGGER para disparar essa sequência antes de cada inserção.
Felizmente, a partir da versão 12c, eles introduziram o GENERATED ALWAYS AS IDENTITY, que deixou tudo mais parecido com os outros SGBDs:

CREATE TABLE funcionario (
    id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    nome VARCHAR2(255),
    data_admissao DATE
);

4. SQLite (O Simples e Local)

No banco queridinho dos aplicativos mobile, o simples fato de você declarar uma coluna como INTEGER PRIMARY KEY já faz com que ela seja auto-incremental por padrão. Mas, se quiser ser muito explícito, pode usar a palavra AUTOINCREMENT.

CREATE TABLE funcionario (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    nome TEXT,
    data_admissao DATE
);

🎯 Conclusão

Entender que o SQL tem suas "gírias locais" dependendo do SGBD é o que separa um iniciante de um desenvolvedor mais maduro (e salva a sua pele em provas de concurso ou testes técnicos de vagas).

Na próxima vez que o seu script falhar ao trocar de banco de dados, lembre-se de checar como aquele sistema específico prefere chamar as coisas!

E você, qual dessas sintaxes está mais acostumado a usar no seu dia a dia? Conta aí nos comentários! 👇

DEV Community