Si solo has guardado valores de campos personalizados en wp_postmeta, nunca has tenido que elegir un tipo de columna, porque solo hay uno: LONGTEXT. Todo (un precio, una fecha, una casilla de verificación, un párrafo) se guarda como cadena de texto y se convierte de nuevo en algo utilizable cuando lo lees. Funciona, pero traslada la responsabilidad de la corrección a cada fragmento de código que lee el valor, para siempre.
Cuando los valores de los campos viven en una tabla real, cada campo tiene un tipo, y ese tipo afecta al tamaño de almacenamiento, al comportamiento de la ordenación y a lo que la base de datos puede validar por ti. Esta es una guía práctica para elegir bien, pensada para quienes se manejan con WordPress pero no han diseñado antes un esquema de base de datos.
Números: INT frente a DECIMAL
Los números enteros (una cantidad en stock, una edad, una cantidad) van en un tipo entero. Aquí solo hay que decidir el tamaño: usa un rango suficiente para los valores que esperas, sin irte a uno innecesariamente grande «por si acaso».
El dinero y cualquier valor con un número fijo de decimales es otro caso, y es uno de los errores más comunes en el diseño de bases de datos en general, no solo en WordPress. Los tipos de coma flotante (FLOAT, DOUBLE) guardan una aproximación de un número decimal, y esa aproximación puede introducir pequeños errores de redondeo al sumar o comparar valores. DECIMAL(10,2) guarda un valor exacto con un número fijo de dígitos antes y después de la coma decimal (en este ejemplo, diez dígitos en total, dos de ellos decimales), y es el tipo correcto para precios, totales y cualquier otro caso en el que «casi exacto» no sea aceptable.
En Mass Custom Fields, un campo Number usa DECIMAL(20,6) por defecto: hasta 14 dígitos antes de la coma decimal y 6 después. En las opciones de columna SQL del campo puedes elegir INT, BIGINT, TINYINT, SMALLINT, MEDIUMINT, FLOAT, DOUBLE u otro DECIMAL(p,s), como DECIMAL(10,2) para un precio. Un valor fuera del rango de la columna se ajusta al valor permitido más cercano en lugar de provocar un error de base de datos, y una columna de números enteros redondea 12.7 a 13. Los detalles están en la referencia de números y rangos.
SELECT p.post_title, d.price
FROM wp_posts p
JOIN wp_wpmcf_fg_product d ON d.mid = p.ID AND d.mtype = 'posts'
WHERE d.price < 100
ORDER BY d.price;Fechas: DATE, DATETIME o un valor de texto
Una columna DATE es la opción adecuada para un valor sin componente horario: una fecha de lanzamiento, una fecha de nacimiento, una fecha de caducidad. Una columna DATETIME es la adecuada cuando la hora importa, como en un hueco de cita. Guardar cualquiera de las dos como texto («2026-08-28») funciona técnicamente para mostrarlas, pero pierdes la posibilidad de ordenar cronológicamente sin una conversión de tipo, y la de hacer aritmética de fechas (comparaciones de antes y después, rangos de fechas) aprovechando un índice.
Los campos Date, Date and time y Time guardan valores nativos DATE, DATETIME y TIME y analizan la entrada de forma estricta, de modo que un valor como 2026-02-30 se rechaza en lugar de guardarse. Las fechas son valores de hora local en la zona horaria de tu sitio, sin conversión al guardar ni al leer. Consulta fecha y hora para ver los formatos aceptados.
El único caso en el que el texto sigue siendo a veces la opción pragmática es un valor que parece una fecha pero que tu aplicación no debería validar como tal; por ejemplo, un campo libre «fundado en» de una página histórica, donde los propios datos de origen son inconsistentes. Un campo Text encaja en ese caso. Cuando el valor es una fecha real que se usa para filtrar u ordenar, usa un tipo de fecha real.
Texto: elige una longitud, no uses «sin límite» por defecto
El núcleo de WordPress suele usar LONGTEXT por defecto para cualquier cosa con forma de texto, porque nunca tiene que adivinar un límite de longitud de antemano. Cuando el campo es tuyo, normalmente conoces el límite: el nombre de un producto no va a ocupar cuatro kilobytes. Un campo Text es por defecto un VARCHAR(255), un campo Email es un VARCHAR(254), y en las opciones de columna SQL puedes fijar una longitud menor, como VARCHAR(100). Una longitud acotada mantiene las filas más pequeñas y hace más barato un índice sobre esa columna.
El contenido de formato libre (una descripción, un cuerpo de texto enriquecido) es el caso legítimo para un tipo de texto más grande. Los campos Text area y WYSIWYG usan LONGTEXT, porque no se conoce la longitud de antemano y no hace falta ordenar ni indexar por el contenido completo.
Booleanos: un tipo verdadero/falso real, no cadenas «yes»/«no»
Un campo con solo dos estados debería ser un tipo booleano de verdad, no una cadena como "yes" o "1" que se compara por igualdad cada vez que se lee. El campo True / false se guarda como TINYINT(1), de modo que puedes filtrar con WHERE featured = 1. Parece un detalle menor hasta que tienes tres representaciones de cadena ligeramente distintas de «verdadero» repartidas por filas antiguas porque un formulario cambió una vez, hace tres años.
Cuando no necesitas decidir nada
La mayoría de las veces, esta decisión no hace falta tomarla a mano. Mass Custom Fields elige un tipo de columna sensato a partir del tipo de campo que seleccionas en el editor (un campo Number pasa a ser una columna decimal, un campo Date pasa a ser una columna de fecha), así que los casos habituales no requieren ningún conocimiento de SQL. La vista general de tipos de campo indica la columna por defecto de cada tipo.
Los índices siguen a los tipos, no al revés
Un índice solo es tan útil como el tipo que tiene debajo. Indexar una columna de texto que guarda números como cadenas sigue exigiendo una conversión de tipo en el momento de la consulta antes de que funcionen las comparaciones, lo que anula buena parte del beneficio de tener el índice. Elige primero el tipo (precios en DECIMAL, fechas en DATE, booleanos en un booleano real) y un índice encima hará lo que esperas.
En las restricciones del campo puedes activar Add index para un índice normal o Unique para valores que no deben repetirse. Los campos guardados como JSON, como las casillas de verificación, las relaciones, los grupos y los repetidores, no se pueden indexar por sí solos. Indexa solo los campos por los que realmente filtras u ordenas, porque cada índice ralentiza un poco las escrituras; el editor avisa a partir de ocho campos indexados en un mismo grupo. La página de opciones comunes de los campos explica estos ajustes.
Cambiar de opinión más adelante
Un tipo elegido hoy no tiene por qué ser definitivo. Si cambias un campo a un tipo compatible, la columna se modifica y los valores se conservan. Si el cambio pudiera perder datos, como de Text a Number, los valores antiguos se copian a una columna de copia de seguridad antes de la conversión. Cambiar un grupo de campos de forma segura explica cada caso.
Conclusión
No existe un tipo «mejor» universal; existe el tipo que se ajusta a cómo se usa realmente el valor. Los números que comparas u ordenas van en tipos numéricos, las fechas en tipos de fecha, y el texto corto y acotado en columnas acotadas. Acertar con esto a nivel de campo es lo que hace más rápida cada consulta sobre esos datos y correcta cada comparación, y es justo la decisión que wp_postmeta nunca te deja tomar.
