Decisión: elegir el tipo de dato adecuado
Elegir un tipo de dato es una de las decisiones más costosas de corregir después: un tipo equivocado produce resultados erróneos (p. ej. float para dinero), espacio desperdiciado y consultas lentas. Este árbol le orienta hacia el tipo adecuado para campos numéricos, de texto, de fecha/hora, de clave (PK), semiestructurados (JSON) y de categoría (ENUM), y destaca trampas clásicas como el dinero y los juegos de caracteres.
¿Qué tipo de datos está almacenando?
El tipo adecuado lo determina la naturaleza de los datos. ¿En qué categoría entra el campo: un número, texto, una fecha/hora, la clave primaria de la tabla, datos flexibles/semiestructurados (JSON) o un conjunto limitado de categorías?
- Valor numérico (cantidad, dinero, medida, contador)
- Texto (nombre, descripción, código)
- Fecha y/u hora
- Estoy diseñando una clave primaria (PK)
- Campos flexibles/anidados/variables (datos semiestructurados)
- Un conjunto limitado y conocido de categorías (estado, tipo, prioridad)
¿El número es entero o decimal? ¿Y es dinero?
En los numéricos, la distinción más crítica es la exactitud. ¿El valor es un entero (cantidad, ID, contador) o un decimal? Si es decimal, ¿es DINERO/un importe financiero? La coma flotante binaria (FLOAT/DOUBLE) nunca se usa para dinero ni donde se requiera exactitud, porque produce errores de redondeo.
- Entero (cantidad, contador, id)
- Dinero o decimal exacto (precio, saldo, tasa)
Recomendación: entero (SMALLINT / INT / BIGINT)
Para los enteros, elija el tipo más pequeño que cubra el rango necesario. Un tipo innecesariamente grande desperdicia espacio y tamaño de índice; pero para los campos que pueden crecer, como contadores/PK, una anchura suficiente es esencial para evitar el desbordamiento.
Recomendación: NUMERIC / DECIMAL; NUNCA FLOAT para dinero
Para dinero y decimales exactos use NUMERIC/DECIMAL de coma fija (exacta). FLOAT/DOUBLE son de coma flotante binaria y no pueden almacenar con exactitud valores como 0.1; las sumas/multiplicaciones producen desviaciones de céntimos, saldos erróneos y problemas de auditoría.
Recomendación: texto: VARCHAR vs TEXT vs CHAR
Para el texto se usa VARCHAR/TEXT para longitud variable y CHAR para longitud realmente fija. En los motores modernos, la diferencia de almacenamiento entre VARCHAR y TEXT es en general despreciable; la verdadera decisión es si imponer un límite semántico (una restricción de longitud).
Recomendación: fecha/hora: TIMESTAMP con zona horaria
Si almacena un instante (la hora de un evento), elija un tipo que tenga en cuenta la zona horaria. Almacenar sin zona horaria provoca cálculos y comparaciones erróneos entre regiones/cambios de horario de verano.
Recomendación: clave primaria: BIGINT vs UUID
Hay dos opciones principales para una PK: un número creciente (BIGINT identity/sequence) o un UUID. Una PK numérica es pequeña y favorable para el índice, pero predecible y requiere generación centralizada; un UUID puede generarse de forma distribuida, pero es más grande y su orden aleatorio puede perjudicar al índice.
Recomendación: JSON / JSONB, con moderación
El tipo JSON es potente para campos con esquema flexible, anidados o dispersos; pero puede perderse la disciplina relacional (restricciones, índices, seguridad de tipos). Regla: lleve los campos fijos y consultados con frecuencia a columnas normales y mantenga en JSON solo la parte realmente variable.
Recomendación: ENUM vs tabla de búsqueda (referencia)
Hay dos opciones para conjuntos de categorías limitados: el tipo ENUM del motor, o una tabla de búsqueda (lookup) + clave foránea. ENUM es compacto y sencillo, pero añadir un valor requiere un cambio de esquema; una tabla de búsqueda es flexible y puede llevar atributos adicionales (descripción, indicador de activo, orden).