Tipos de datos en SQLite
SQLite es un motor de base de datos muy particular porque no utiliza un sistema de tipos estricto como otros motores más tradicionales. En lugar de obligar a que cada columna tenga un tipo fijo e inamovible, SQLite aplica un modelo basado en afinidades. Esto significa que cada columna sugiere el tipo de dato que espera, pero el motor puede almacenar valores de distinta naturaleza si no existe una regla que lo prohíba.
Las afinidades representan la forma en que SQLite intenta interpretar y almacenar un valor. Aunque un dato pueda llegar en distintos formatos, SQLite trata de adaptarlo al tipo más adecuado según la afinidad de la columna. Este enfoque ofrece mucha flexibilidad, pero también exige que el desarrollador sea consciente de cómo se comporta el motor para evitar errores silenciosos o resultados inesperados.
Afinidad INTEGER
La afinidad INTEGER indica que los valores están orientados a números enteros. Cuando se almacena un dato que puede interpretarse como un entero, SQLite intentará conservarlo de esa manera. Esta afinidad es adecuada para valores que representan cantidades, contadores, identificadores numéricos o cualquier información que solo necesite números sin decimales.
Afinidad REAL
La afinidad REAL está pensada para números decimales o valores que pueden perder precisión si se representaran como enteros. SQLite procurará almacenar el valor como número en coma flotante siempre que sea posible. Se utiliza habitualmente para precios, mediciones o cualquier tipo de dato que requiera decimales.
Afinidad TEXT
La afinidad TEXT se centra en el almacenamiento de cadenas de caracteres. Si el valor recibido puede interpretarse como texto, SQLite lo guardará tal cual. Esta afinidad es útil para nombres, descripciones, direcciones, códigos o cualquier información basada en palabras. Es importante recordar que SQLite puede almacenar cualquier valor como texto si no existe una indicación clara que lo convierta en número.
Afinidad BLOB
La afinidad BLOB se usa para almacenar datos sin interpretar: archivos, binarios, imágenes o cualquier contenido que deba conservarse exactamente igual a como llega. A diferencia de otros tipos, SQLite no intenta transformar ni analizar el valor, sino que lo guarda de manera cruda. Aunque este tipo existe, es poco habitual en proyectos simples basados en SQLite.
Afinidad NUMERIC
La afinidad NUMERIC es una de las más flexibles. Intenta interpretar el valor como número siempre que sea posible, ya sea entero o decimal. Sin embargo, si el dato no puede convertirse, se almacenará tal cual. Esta afinidad es útil cuando se desea un comportamiento híbrido en el que los números tengan prioridad, pero no se quieran rechazar otros formatos.
¿Cómo decide SQLite el tipo final al almacenar un valor?
Cuando se guarda un dato, SQLite sigue una serie de pasos internos. En primer lugar, analiza el valor recibido y lo compara con la afinidad de la columna. Si encaja y puede convertirse, adopta el tipo más adecuado. Si no es posible la conversión, lo almacena sin aplicar transformación. Esta mecánica hace que SQLite sea muy flexible, pero implica que un mismo campo podría terminar conteniendo distintos tipos de valores si no se presta atención al diseño de la base de datos.
Buenas prácticas al elegir tipos en SQLite
Aunque SQLite permite almacenar casi cualquier cosa en cualquier columna, lo recomendable es seleccionar afinidades que representen correctamente la naturaleza del dato. Esto facilita la lectura del esquema, evita interpretaciones incorrectas y crea una base sólida para futuras validaciones. También es importante ser coherente en todo el proyecto. Si se decide que las fechas se representarán como texto en formato legible, lo ideal es mantener ese criterio en todas las tablas. La consistencia es más importante que el formato específico elegido.
Fechas y formatos recomendados
SQLite no tiene un tipo de dato específico para fechas u horas. En la práctica, la mayoría de proyectos utiliza cadenas de texto para representarlas, normalmente en un formato estándar y consistente. La elección del formato exacto dependerá del estilo y las necesidades del proyecto, pero lo fundamental es establecer desde el principio cuál será la convención utilizada y respetarla siempre.
Aquí tienes una tabla clara y sencilla que resume los tipos de datos de SQLite, su uso recomendado y un ejemplo ilustrativo de cada uno.
Tipos de datos en SQLite
| Tipo de dato (afinidad) | Descripción ampliada | Uso recomendado | Ejemplos de valores | Advertencias habituales | Recomendaciones prácticas |
|---|---|---|---|---|---|
| INTEGER | Representa números enteros. SQLite intentará convertir a entero cualquier valor que sea interpretable como tal. | Contadores, identificadores, cantidades, índices numéricos. | 0, 12, -5, "0042" → se almacenaría como 42 | Si el valor no es convertible a entero (por ejemplo, "hola"), SQLite lo almacenará como texto. | Úsalo para cualquier dato que no requiera decimales. Mantén la coherencia en toda la aplicación. |
| REAL | Representa valores decimales en coma flotante. SQLite convierte valores numéricos compatibles a formato REAL. | Precios, medidas, porcentajes, cálculos con decimales. | 3.14, 19.95, -0.5, "2.718" → convertido a REAL | Los formatos con coma decimal europea (ej. "19,95") se almacenan como texto, no como número. | Usa siempre punto para decimales. Comprueba la conversión cuando los datos provienen de formularios. |
| TEXT | Almacena cadenas de caracteres sin conversión. Es el tipo más flexible y aceptará prácticamente cualquier dato como texto. | Nombres, direcciones, descripciones, códigos, fechas en formato legible. | "Ana", "2025-01-01", "España", "123" | Si usas TEXT para fechas, compararlas requiere un formato consistente. Valores numéricos almacenados como texto no se comportarán como números. | Para fechas, elige siempre un único formato (recomendado: YYYY-MM-DD). Evita mezclar texto con números si luego necesitarás cálculos. |
| BLOB | Guarda datos binarios sin interpretar ni modificar. Útil para contenido que debe conservarse idéntico. | Imágenes, archivos binarios, datos cifrados o comprimidos. | bytes de una imagen, contenido de un archivo PDF | No se puede leer directamente; necesita tratamiento en la aplicación. Puede aumentar mucho el tamaño de la base de datos. | Evita guardar archivos grandes dentro de SQLite. Úsalo solo para datos pequeños y necesarios. |
| NUMERIC | Intenta almacenar valores como números enteros o reales. Si la conversión no es posible, conserva el valor original. | Casos híbridos en los que la mayor parte de los valores serán numéricos, pero podrían aparecer datos no estrictamente numéricos. | 10, 10.5, "25", "25.00", "hola" → se almacena tal cual | Puede provocar inconsistencias si no controlas la entrada. Una columna NUMERIC podría terminar con valores de tipos distintos. | Úsalo con precaución. Si necesitas robustez, considera validar los datos en la aplicación antes de guardarlos. |
Apunte importante
Elección entre TEXT, REAL o NUMERIC para fechas y cantidades:
Al trabajar con SQLite, es habitual preguntarse cuál de estos tres tipos conviene usar para almacenar fechas o cantidades. Aunque SQLite es flexible, elegir el tipo adecuado mejora la coherencia y reduce errores en consultas posteriores.
- TEXT para fechas. TEXT es la opción más clara y predecible si se usa un formato consistente, preferiblemente el formato ISO: YYYY-MM-DD o YYYY-MM-DDTHH:MM:SS Las comparaciones y ordenaciones funcionan correctamente siempre que el formato mantenga este orden jerárquico. Si en algún momento mezclas otros formatos, las fechas dejarán de compararse adecuadamente. TEXT ofrece legibilidad y portabilidad, pero depende estrictamente de la coherencia del formato elegido.
- REAL para cantidades decimales. REAL es adecuado para precios, medidas y cualquier valor que necesite decimales. Permite operar con ellos directamente sin conversión adicional. Es importante recordar que utiliza coma flotante, por lo que puede haber pequeñas imprecisiones internas. Si el valor tiene decimales, debe usarse el punto como separador; si introduces valores con coma, SQLite los interpretará como texto.
- NUMERIC como opción híbrida. NUMERIC intenta convertir los valores a número, pero conserva el formato original si no puede interpretarlos. Esto significa que una misma columna podría terminar almacenando cantidades numéricas junto con cadenas no numéricas. Es una opción flexible, pero puede dificultar validaciones o cálculos posteriores. Se recomienda cuando los datos provienen de fuentes variadas y no se desea imponer un tipo completamente estricto.
En resumen, TEXT es ideal para fechas siempre que respetes un formato uniforme, REAL es la mejor elección para valores decimales, y NUMERIC funciona como solución intermedia cuando no puedes garantizar la validez de todos los datos desde el principio.