Preferir tabelas STRICT no SQLite

Artigo original ↗ Discussão no Hacker News ↗

A nova opção de tabelas STRICT do SQLite reacendeu o debate sobre a escolha histórica do banco de dados de permitir tipos de coluna flexíveis e, em grande parte, não verificados. Os defensores de STRICT argumentam que impor tipos por padrão evitaria corrupção sutil de dados, tornaria esquemas um contrato mais confiável e alinharia o SQLite a outros bancos relacionais, enquanto os críticos contrapõem que a tipagem dinâmica e padrões permissivos são essenciais para casos de uso embarcados, de aplicativo único, e para a compatibilidade retroativa. A conversa também aborda armadilhas relacionadas — como foreign keys e o modo WAL serem opcionais, e a ausência de tipos nativos de data/booleano — além de ferramentas e contornos para desenvolvedores que querem garantias mais fortes.

Tabelas STRICT vs. comportamento padrão

  • Muitos argumentam que tabelas STRICT deveriam ser o padrão, ou até mesmo o único modo em versões futuras.
  • Outros contrapõem que STRICT é apenas uma preferência; o comportamento atual do SQLite é intencional e se encaixa no seu nicho.
  • Alguns sugerem uma pragma global ou “conjuntos padrão”/padrões versionados (por exemplo, “usar os padrões de 2026.1”) para सक्षमitar a rigidez e outras opções mais seguras sem quebrar código antigo.

Filosofia de tipagem e história do SQLite

  • O SQLite começou em um mundo de “tudo é string/número” (Tcl, armazenamento no estilo dbm), e sua tipagem dinâmica em grande parte persistiu até o SQLite 3.
  • A documentação do projeto defende explicitamente a tipagem flexível; críticos no tópico muitas vezes consideram essas justificativas pouco convincentes ou feitas a posteriori.
  • Os defensores enfatizam o SQLite como “concorrência para fopen”, não Oracle/Postgres, e veem verificações rigorosas em tempo de execução como sobrecarga opcional quando você pode provar a correção no código da aplicação.

Preocupações práticas: tipos, datas, booleanos

  • Reclamações comuns:
    • Tipos de coluna não são verificados por padrão.
    • Falta de tipos nativos DATE/TIMESTAMP/BOOL, especialmente incômoda no modo STRICT.
    • Surpresas como colunas inteiras aceitando texto arbitrário e bytes NUL em strings afetando funções como length().
  • Contornos: armazenar datas como texto ou timestamps Unix; booleanos como inteiros ou bitfields; impor via restrições CHECK.

Compatibilidade retroativa e padrões

  • O SQLite raramente altera padrões (por exemplo, foreign keys desativadas por padrão, WAL desativado por padrão) para evitar quebrar software existente.
  • Alguns veem isso como responsabilidade; outros veem isso como forçar novos usuários a aprender e desativar “armadilhas” uma por uma.
  • Há debate sobre se a aceitação surpreendente de tipos é um modo de falha pior do que quebrar código antigo durante atualizações.

Migrações, ferramentas e modos

  • Migrações de esquema no SQLite são vistas como trabalhosas; ferramentas e padrões de terceiros tentam simplificar isso.
  • Tabelas STRICT não podem ser alternadas via um simples ALTER; a abordagem típica é recriar e copiar, embora algumas ferramentas automatizem isso.
  • As opiniões divergem sobre se o modo strict melhora integrações com linguagens de nível mais alto (por exemplo, ORMs em Rust/Go) ou complica o mapeamento de tipos.