En primer lugar, realmente no quieres hacer eso. Una columna en un RDBMS está destinada a ser atómica, ya que contiene una y solo una pieza de información. Intentar almacenar más de un dato en una columna es una violación de la primera forma normal.
Si es absolutamente necesario hacerlo, debe convertir los datos en un formulario que se pueda almacenar como un solo elemento de datos, generalmente una cadena. Puede usar el mecanismo serialize() de PHP, análisis XML (si los datos resultan ser un árbol de documentos), json_encode(), etc.
Pero, ¿cómo consulta esos datos de manera efectiva? La respuesta es que no puedes.
Además, si alguien más se hace cargo de su proyecto en una fecha posterior, realmente lo va a molestar, porque es horrible trabajar con datos serializados en una base de datos. Lo sé porque he heredado este tipo de proyectos.
¿Mencioné que realmente no quieres hacer eso? Debe repensar su diseño para que pueda almacenarse más fácilmente en términos de filas atómicas. Use otra tabla para estos datos, por ejemplo, y use claves foráneas para relacionarla con el registro maestro. Se llaman bases de datos relacionales por una razón.
ACTUALIZAR :Me han preguntado sobre los requisitos de almacenamiento de datos, como si una sola fila sería más económica en términos de almacenamiento. La respuesta es, en los casos típicos, no, no lo es, y en los casos en que la respuesta es sí, el precio que paga no vale la pena pagar.
Si usa una tabla dependiente de 2 columnas (1 columna para la clave externa del registro al que pertenece la muestra, una para una sola muestra), cada columna requerirá, en el peor de los casos, 16 bytes (8 bytes para una columna de clave de entero largo, 8 bytes para un número de punto flotante de precisión doble). Para 100 registros, son 1600 bytes (ignorando la sobrecarga de db).
Para una cadena serializada, almacena en el mejor de los casos 1 byte por carácter en la cadena. No puede saber cuánto va a durar la cadena, pero si asumimos 100 muestras con todos los datos almacenados por alguna coincidencia artificial, todas entre 10000,00 y 99999,99 con solo 2 dígitos después del punto decimal, entonces usted estamos mirando 8 bytes por muestra. En este caso, todo lo que ha ahorrado es la sobrecarga de las claves externas, por lo que la cantidad de almacenamiento requerida es de 800 bytes.
Eso, por supuesto, se basa en muchas suposiciones, como que la codificación de caracteres siempre es de 1 byte por carácter, las cadenas que componen las muestras nunca superan los 8 caracteres, etc.
Pero, por supuesto, también está la sobrecarga de cualquier mecanismo que utilice para serializar los datos. El método absolutamente más simple, CSV, significa agregar una coma entre cada muestra. Eso agrega n-1 bytes a la cadena almacenada. Entonces, el ejemplo anterior ahora sería de 899 bytes, y eso es con el esquema de codificación más simple. JSON, XML, incluso las serializaciones de PHP agregan más caracteres generales que esto, y pronto tendrá cadenas que superan los 1600 bytes. Y todo esto con la suposición de una codificación de caracteres de 1 byte.
Si necesita indexar las muestras, los requisitos de datos crecerán aún más desproporcionadamente frente a las cadenas, porque un índice de cadena es mucho más costoso en términos de almacenamiento que un índice de columna de punto flotante.
Y, por supuesto, si sus muestras comienzan a agregar más dígitos, el almacenamiento de datos aumenta aún más. 39281.3392810 no se podrá almacenar en 8 bytes como una cadena, incluso en el mejor de los casos.
Y si los datos se serializan, la base de datos no se puede manipular. No puede ordenar las muestras, hacer ningún tipo de operación matemática con ellas, ¡la base de datos ni siquiera sabe que son números!
Sin embargo, para ser honesto, el almacenamiento es ridículamente barato en estos días, puede comprar varias unidades de TB por pequeñas sumas. ¿El almacenamiento es realmente tan crítico? A menos que tenga cientos de millones de registros, dudo que lo sea.
Es posible que desee consultar un libro llamado SQL Antipatterns
