Preferir tablas STRICT en SQLite

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

La nueva opción de tablas STRICT de SQLite ha reavivado el debate sobre la elección histórica de la base de datos de permitir tipos de columna flexibles y, en gran medida, no aplicados. Quienes apoyan STRICT sostienen que imponer tipos por defecto evitaría corrupciones sutiles de datos, haría que los esquemas fueran un contrato más fiable y alinearía SQLite con otras bases de datos relacionales, mientras que los críticos responden que el tipado dinámico y los valores predeterminados permisivos son esenciales para casos de uso incrustados y de una sola aplicación, así como para la compatibilidad hacia atrás. La conversación también aborda otros riesgos similares, como que las claves foráneas y el modo WAL sean optativos, y la ausencia de tipos nativos de fecha/booleano, además de herramientas y soluciones para desarrolladores que quieren garantías más fuertes.

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.