Preferir tabelas STRICT no SQLite

Artigo original ↗ Discussão no Hacker News ↗

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.