Imagine Que Temos Uma Tabela Com Nome Livro E Campos

Montando uma tabela de livros no banco de dados

imagina que temos uma tabela com nome livro e campos — é assim que todo mundo começa quando vai criar o schema de alguma coisa relacionada a livros. O problema é que a maioria das pessoas para no primeiro passo e esquece de pensar nos detalhes que aparecem depois. Vou explicar como isso funciona na prática, porque já vi muita coisa dar errado por falta de planejamento básico.

imagina que temos uma tabela com nome livro e campos

A estrutura básica seria algo assim: coluna ID (inteiro, chave primária), titulo (texto), autor (texto), isbn (texto ou varchar), ano_publicacao (inteiro ou date), editora (texto), preco (decimal), quantidade_estoque (inteiro). Parece simples, mas é aí que as pessoas cometem os erros. O ISBN, por exemplo, todo mundo coloca como texto. Errado. ISBN pode conter o caractere X no final (nas versões antigas de 10 dígitos) e também pode ter hífens. Se você colocar como inteiro, vai perder dados. Use varchar com tamanho 13 ou 17, dependendo da versão. Já perdi horário demais corrigindo isso em produção. O campo autor também merece atenção. Se você colocar uma única coluna autor, vai ter problemas na hora de buscar livros de um mesmo escritor ou listar todos os autores de um gênero. A solução mais comum é criar uma tabela separada de autores e fazer uma relação muitos-para-muitos com uma tabela intermediária. Ou, se quiser manter tudo em uma coluna só para simplificar, pelo menos use um campo de texto livre e documente que a busca por autor será imprecisa.

O preço precisa ser decimal, nunca float. Float tem problemas de precisão que parecem inofensivos até você fazer uma soma de milhares de linhas e descobrir que o total não bate. Decimal(10,2) resolve. E se trabalha com moedas estrangeiras, pense em usar uma tabela de taxas de câmbio em vez de armazenar valores fixos. Acho que o campo mais subestimado é o ano_publicacao. Colocar como integer parece lógico, mas e quando o ano é desconhecido? Ou quando o livro tem data aproximada? Eu costumo usar nullable e, quando necessário, adicionar uma coluna adicional com ano_estimado e uma flag que indica se o valor é preciso ou aproximado. Já precisei justificar essa decisão num review de schema e, honestamente, foi o que mais fez sentido quando fomos processar livros de edições antigas sem data registrada. Outra coisa que quase ninguém pensa:. Se você vai fazer busca por titulo, isbn ou autor com frequência, crie indexes. Mas indexar titulo como texto completo é pesado. Melhor usar full-text search se o banco suportar, ou criar uma tabela de categorias/gêneros separada e relacionar por FK em vez de confiar em LIKE '%palavra%'. Esse tipo de query mata o desempenho em tabelas grandes.

Se a tabela for pequena, digamos menos de mil linhas, dá para arrumar com constraints simples e viver bem. A partir de dez mil linhas, a escolha dos tipos de dado e dos indexes faz diferença real no tempo de resposta. E a partir de cem mil, você vai perceber que não pensou em nada disso quando montou a tabela. Para quem quer um modelo pronto para copiar, o padrão mais seguro que eu uso é:

• id: INT AUTO_INCREMENT PRIMARY KEY
• titulo: VARCHAR(255) NOT NULL
• autor_id: INT (FK para tabela autores)
• isbn: VARCHAR(17)
• ano_publicacao: YEAR NULL
• editora: VARCHAR(100)
• preco: DECIMAL(10,2) NOT NULL
• quantidade_estoque: INT DEFAULT 0
• criado_em: TIMESTAMP DEFAULT CURRENT_TIMESTAMP

Adicione indexes em isbn, titulo e autor_id. Considere um índice composto em (isbn, ano_publicacao) se for comum buscar por essas duas colunas juntas. Se precisar de algo mais robusto, como controle de edições múltiplas do mesmo livro ou versões com capas diferentes, aí sim a coisa começa a complicar e vale a pena pensar num modelo mais normalizado desde o início.