Preferir tablas STRICT en SQLite

Artículo original ↗ Discusión en Hacker News ↗

Tablas STRICT vs. comportamiento predeterminado

  • Muchos sostienen que las tablas STRICT deberían ser el valor predeterminado, o incluso el único modo en versiones futuras.
  • Otros responden que STRICT es solo una preferencia; el comportamiento actual de SQLite es intencional y encaja con su nicho.
  • Algunos sugieren una pragma global o “conjuntos predeterminados”/predeterminados versionados (por ejemplo, “usar los valores predeterminados de 2026.1”) para habilitar la estricticidad y otras opciones más seguras sin romper código القديم.

Filosofía e historia de tipado de SQLite

  • SQLite comenzó en un mundo de “todo es una cadena/número” (Tcl, almacenamiento al estilo dbm), y su tipado dinámico en gran medida persistió hasta SQLite 3.
  • La documentación del proyecto defiende explícitamente el tipado flexible; los críticos en el hilo a menudo encuentran estas justificaciones poco convincentes o hechas a posteriori.
  • Los defensores enfatizan SQLite como “competencia para fopen”, no para Oracle/Postgres, y ven las comprobaciones estrictas en tiempo de ejecución como una sobrecarga opcional cuando puedes demostrar la corrección en el código de la aplicación.

Preocupaciones prácticas: tipos, fechas, booleanos

  • Quejas comunes:
    • Los tipos de columna no se imponen por defecto.
    • Falta de tipos nativos DATE/TIMESTAMP/BOOL, especialmente incómodo en modo STRICT.
    • Sorpresas como columnas de enteros aceptando texto arbitrario, y bytes NUL en cadenas afectando funciones como length().
  • Soluciones alternativas: guardar fechas como texto o marcas de tiempo Unix; booleanos como enteros o bitfields; imponer con restricciones CHECK.

Compatibilidad hacia atrás y valores predeterminados

  • SQLite muy rara vez cambia los valores predeterminados (por ejemplo, claves foráneas desactivadas por defecto, WAL desactivado por defecto) para evitar romper software existente.
  • Algunos ven esto como responsable; otros lo ven como obligar a los nuevos usuarios a aprender y desactivar “footguns” uno por uno.
  • Hay debate sobre si aceptar tipos de forma sorprendente es un peor modo de fallo que romper código antiguo durante las actualizaciones.

Migraciones, herramientas y modos

  • Las migraciones de esquema en SQLite se consideran engorrosas; herramientas y patrones de terceros intentan simplificarlas.
  • Las tablas STRICT no pueden activarse o desactivarse con un simple ALTER; el enfoque típico es recrear y copiar, aunque algunas herramientas lo automatizan.
  • Las opiniones divergen sobre si el modo estricto mejora las integraciones con lenguajes de nivel superior (p. ej., ORMs de Rust/Go) o complica el mapeo de tipos.