CREATE TABLE em SQL: Design de esquema mestre e melhores práticas

A instrução ` CREATE TABLE ` é a base de qualquer projeto de banco de dados relacional. Ele define quais dados você guarda, como eles são organizados e as regras que garantem a precisão deles.

Neste tutorial, vou te mostrar o básico da sintaxe do CREATE TABLE, opções práticas de design e exemplos reais pra te ajudar a criar tabelas intuitivas e eficientes que atendam às necessidades atuais e ao crescimento futuro.

Se você é novo no SQL, considere começarcom nosso curso Introdução ao SQL ou curso SQL Intermediário para construir uma base sólida. Além disso, acho que a Folha de Referência Básica do SQL, que você pode baixar, é uma referência útil, pois contém todas as funções SQL mais comuns.

O papel do CREATE TABLE no design de bancos de dados

A instrução ` CREATE TABLE ` é o comando principal da Linguagem de Definição de Dados (DDL) que define como seus dados são armazenados, organizados e acessados. Antes de escrever, você deve decidir o que a tabela representa, como ela se conecta às outras e como sua estrutura vai ajudar nas consultas futuras. 

A sintaxe básica inclui o nome da tabela seguido por uma lista de colunas, cada uma definida com um tipo de dados e restrições opcionais. Dá uma olhada na sintaxe abaixo:

-- Create table syntax
CREATE TABLE schema_name.table_name (
    column_name data_type constraint,
    column_name data_type constraint,
    column_name data_type constraint,
    ...
);

Onde:

• schema_name: Espaço de nomes opcional para organizar tabelas.

• table_name: Nome claro e descritivo para a entidade.

• column_name: O nome de um campo (atributo) na tabela.

• data_type: Define o formato, como INT, VARCHAR ou DATE.

• constraint: Regras opcionais como PRIMARY KEY, NOT NULL ou UNIQUE.

Essa sintaxe é consistente nas principais plataformas SQL, como MySQL, PostgreSQL e SQL Server, com apenas pequenas diferenças de dialeto nas opções avançadas. Então, é bom seguir regras claras de nomenclatura para nomes de tabelas e colunas, pra manter a consistência nessas plataformas.

Definindo colunas, tipos de dados e restrições

Depois de vermos como criar a estrutura da tabela, vamos ver como definir as colunas que moldam os dados. Uma definição de coluna tem três partes: o nome da coluna, o tipo de dados e as restrições.

Escolher os tipos de dados certos otimiza o armazenamento e o desempenho das consultas, como usar INT para IDs numéricos ou VARCHAR para textos de comprimento variável. Escolhas ruins, como usar tipos de dados grandes sem necessidade, podem fazer com que você desperdice espaço e deixe as consultas mais lentas.

As restrições fazem com que as regras que mantêm seus dados confiáveis e conectados sejam seguidas. Por exemplo, o PRIMARY KEY identifica cada linha de forma única, e o FOREIGN KEY conecta tabelas para manter as relações. A restrição DEFAULT define valores automáticos, enquanto CHECK garante que os valores atendam a critérios específicos. 

Dá uma olhada no exemplo abaixo, que mostra restrições e tipos de dados bem definidos. 

-- Create table syntax with data types and constraints defined
CREATE TABLE orders (
    order_id INT PRIMARY KEY,          -- Proper PK
    user_id INT NOT NULL,              -- Required relationship
    total DECIMAL(10,2) NOT NULL,      -- Exact monetary value
    status VARCHAR(20) DEFAULT 'new',  -- Controlled default
    FOREIGN KEY (user_id) REFERENCES users(user_id)  -- Enforce relationship
);

A consulta a seguir mostra um exemplo de design de tabela ruim, onde chaves e restrições ausentes, tipos superdimensionados e escolhas imprecisas de dados podem resultar em armazenamento inconsistente ou ineficiente.

CREATE TABLE orders (
    id VARCHAR(50),        -- Unnecessary string PK
    user VARCHAR(255),     -- No relationship enforced
    total FLOAT,           -- Risky for money calculations
    status TEXT            -- No constraints or defaults
);

Como boa prática, certifique-se sempre de definir explicitamente os tipos de dados e as restrições de acordo com o design das suas tabelas e os requisitos comerciais.

Recomendofazer nosso curso Introdução a bancos de dados relacionais em SQL paraaprender a criar tabelas, aplicar relações e restrições entre tabelas.

Criando tabelas para situações reais

Depois que você entender a sintaxe do CREATE TABLE, vou te mostrar como criar tabelas que combinam com os fluxos de trabalho do mundo real. 

Exemplo de comércio eletrônico

Vamos supor que você queira criar um sistema de comércio eletrônico. Você vai ter as tabelas customers, orders e products com chaves estrangeiras ligando essas tabelas para garantir as relações e a integridade referencial.

Primeiro, você vai criar a tabela customers com o seguinte esquema para guardar os perfis dos usuários:

-- Create customers table to store user profiles
CREATE TABLE customers (
    customer_id INT PRIMARY KEY,               
    name VARCHAR(150) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

Em segundo lugar, a tabela products vai ter o seguinte esquema para guardar cada item na plataforma.

-- Create products table for catalog of items for sale
CREATE TABLE products (
    product_id INT PRIMARY KEY,
    name VARCHAR(200) NOT NULL,
    price DECIMAL(10,2) NOT NULL,               -- Accurate money type
    stock INT CHECK (stock >= 0),               -- Prevent negative inventory
    created_at TIMESTAMP DEFAULT NOW()
);

Por último, você vai ter a tabela orders para guardar as compras feitas pelos clientes.

-- Create orders table
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT NOT NULL,                   -- Link order → customer
    order_date TIMESTAMP DEFAULT NOW(),
    total_amount DECIMAL(10,2) NOT NULL,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
    -- Enforce relationship and ensure customer exists
);

Ao criar várias tabelas, sempre use a restrição de chave primária ( FOREIGN KEY ) para definir a relação entre uma coluna na tabela secundária e a chave primária ( PRIMARY KEY ) na tabela principal para garantir a integridade referencial. No nosso exemplo, essa relação garante que você não possa ter um pedido para um cliente que não existe.

Tabelas temporárias vs. tabelas clonadas

Às vezes, você pode querer criar uma tabela para um caso de uso rápido ou para testar uma transformação de dados sem afetar o esquema ativo. Nesse caso, você pode criar uma tabela temporária ou clonada. Vamos ver como criar cada um deles:

• Tabelas temporárias: São tabelas de curta duração, muitas vezes visíveis apenas para a sessão atual do banco de dados, que são automaticamente excluídas quando a sessão termina. São úteis para transformações complexas de dados, processamento de dados em várias etapas ou testes. A consulta abaixo mostra como criar uma tabela temporária no PostgreSQL.

-- Temporary copy for short-term analysis
CREATE TEMPORARY TABLE temp_sales AS
SELECT * FROM sales
WHERE sale_date >= CURRENT_DATE - INTERVAL '7 days';

• Tabelas clonadas: São cópias exatas das tabelas que já existem, incluindo índices e restrições. São úteis para transações sensíveis, nas quais a integridade dos dados deve ser preservada durante as modificações.

-- Create quick structural clone for testing or recovery
CREATE TABLE orders_backup AS
SELECT * FROM orders;

Normalização vs. desnormalização

Ao projetar tabelas, equilibrar a normalização e a desnormalização depende de casos de uso específicos, volume de dados e padrões de consulta para otimizar a eficácia e a manutenção do sistema. Abaixo está um resumo de quando usar cada método:

• Normalização: Esse método envolve dividir tabelas grandes em tabelas menores e relacionadas, para que cada dado não essencial seja armazenado uma única vez. A vantagem é que fica mais eficiente, com menos coisas a mais e mais fácil de cuidar.
• Desnormalização: Isso envolve a adição estratégica de redundância, como incluir o nome do cliente em cada linha do pedido. Esse método melhora o desempenho de leitura para requisitos específicos de relatórios ou análises, principalmente quando as junções são lentas.

Otimizando e automatizando a criação de tabelas

Ao criar tabelas para o seu banco de dados, você deve ter em mente o desempenho e a manutenção futura. Com base na minha vasta experiência em design de bancos de dados, acho que as seguintes técnicas de otimização são bem úteis:

• Indexação: Adicionar índices nas colunas que você usa bastante nas pesquisas deixa as consultas mais rápidas. Quando você define o ` PRIMARY KEY`, ele cria automaticamente um índice exclusivo.
• Particionamento: Para tabelas grandes, o particionamento divide os dados em partes menores e mais fáceis de gerenciar com base em critérios como data, aumentando a eficiência da consulta ao limitar o escopo da varredura.
• Colunas calculadas: Algumas bases de dados, como o SQL Server e o PostgreSQL, permitem definir colunas calculadas que calculam dinamicamente valores a partir de outras colunas. Essa abordagem pode reduzir o armazenamento de dados redundantes e melhorar a velocidade das consultas.

Nos fluxos de trabalho modernos, a automação tem um papel importante no design e gerenciamento de esquemas. Você pode contar com as seguintes ferramentas e consultas para documentar, replicar ou automatizar o processo:

Para o planejamento visual, você pode usar ferramentas GUI,como pgAdmin, MySQL Workbench ou SQL Server Management Studio, para gerar scripts DDL, desenhar diagramas de relacionamento e melhorar a colaboração entre os membros técnicos e não técnicos da equipe.

Erros comuns e melhores práticas

Criar tabelas eficientes e fáceis de manter no SQL garante que seu banco de dados funcione da melhor maneira possível. Aqui vão algumas dicas que eu recomendo quando você estiver criando tabelas em SQL: 

• Supernormalização: Dividir tabelas em tantas partes pequenas pode complicar as junções e tornar as consultas mais lentas, enquanto a subnormalização pode levar à redundância de dados. Para evitar isso, use sempre 3NF inicialmente e, depois, use a desnormalização apenas para tabelas de relatórios específicas, nas quais você prioriza a velocidade de leitura em detrimento da simplicidade de atualização.

• Projeto de restrição inadequado: Não definir suas restrições, como chaves estrangeiras ausentes, pode levar a registros órfãos ou dados inconsistentes que são difíceis de limpar. Sempre especifique um índice em cada coluna que serve como e FOREIGN KEY e para garantir que as junções sejam rápidas.

• Nomes e documentação claros: Sempre use nomes de tabelas e colunas que sejam fáceis de entender e descrevam bem o que são. Mantenha um registro simples das alterações feitas no esquema e evite usar abreviações que os futuros desenvolvedores possam não entender.

• Permissões e considerações de segurança: Ao projetar tabelas para ambientes de produção, conceda apenas os privilégios necessários, como aqueles para criar, alterar ou excluir tabelas, e separe o acesso de leitura/gravação para proteger dados críticos. Além disso, use controles de esquema e registros de auditoria para acompanhar as mudanças, evitando acessos não autorizados e garantindo a conformidade e a segurança dos dados.

Conclusão

Com os avanços nas plataformas em nuvem, a declaração “ CREATE TABLE ” está ficando mais flexível. Agora, as ferramentas de automação e os recursos sem servidor simplificam o gerenciamento de esquemas e as migrações. Recomendo explorar tópicos como estruturas de migração de esquemas (Flyway, Liquibase), modelagem dimensional e estratégias avançadas de normalização e desnormalização para te ajudar a construir bancos de dados escaláveis.

Também recomendo fazer nosso Design de Banco de Dados, onde você vai aprender a criar e gerenciar bancos de dados e escolher o DBMS certo para suas necessidades. Por fim, experimente nosso caminho de carreira de Engenheiro de Dados Associado em SQL para aprender o básico de engenharia de dados e armazenamento de dados em um programa.