Primeiro, você realmente não quer fazer isso. Uma coluna em um RDBMS deve ser atômica, pois contém uma e apenas uma informação. Tentar armazenar mais de um dado em uma coluna é uma violação da primeira forma normal.

Se você realmente precisar fazer isso, precisará converter os dados em um formulário que possa ser armazenado como um único item de dados, geralmente uma string. Você pode usar o mecanismo serialize() do PHP, análise XML (se os dados forem uma árvore de documentos), json_encode(), etc.

Mas como você consulta esses dados de forma eficaz? A resposta é que você não pode.

Além disso, se outra pessoa assumir seu projeto posteriormente, você realmente vai incomodá-la, porque dados serializados em um banco de dados são horríveis de se trabalhar. Eu sei porque herdei esses projetos.

Eu mencionei que você realmente não quer fazer isso? Você precisa repensar seu design para que ele possa ser armazenado mais facilmente em termos de linhas atômicas. Use outra tabela para esses dados, por exemplo, e use chaves estrangeiras para relacioná-los ao registro mestre. Eles são chamados de bancos de dados relacionais por um motivo.

ATUALIZAÇÃO :me perguntaram sobre os requisitos de armazenamento de dados, como se uma única linha seria mais barata em termos de armazenamento. A resposta é, em casos típicos, não, não é, e nos casos em que a resposta é sim, o preço que você paga por isso não vale a pena pagar.

Se você usar uma tabela dependente de 2 colunas (1 coluna para a chave estrangeira do registro ao qual a amostra pertence, uma para uma única amostra), cada coluna exigirá na pior das hipóteses 16 bytes (8 bytes para uma coluna de chave longint, 8 bytes para um número de ponto flutuante de precisão dupla). Para 100 registros, são 1600 bytes (ignorando a sobrecarga de banco de dados).

Para uma string serializada, você armazena no melhor caso 1 byte por caractere na string. Você não pode saber quanto tempo a string terá, mas se assumirmos 100 amostras com todos os dados armazenados por alguma coincidência artificial, todos caindo entre 10.000,00 e 99.999,99, com apenas 2 dígitos após o ponto decimal, então você estou olhando para 8 bytes por amostra. Nesse caso, tudo o que você salvou é a sobrecarga das chaves estrangeiras, portanto, a quantidade de armazenamento necessária chega a 800 bytes.

Isso, é claro, é baseado em muitas suposições, como a codificação de caracteres sempre sendo 1 byte por caractere, as strings que compõem as amostras nunca tendo mais de 8 caracteres, etc.

Mas é claro que também há a sobrecarga de qualquer mecanismo que você use para serializar os dados. O método mais simples absoluto, CSV, significa adicionar uma vírgula entre cada amostra. Isso adiciona n-1 bytes à string armazenada. Portanto, o exemplo acima agora teria 899 bytes, e isso com o esquema de codificação mais simples. JSON, XML e até mesmo serializações PHP adicionam mais caracteres de sobrecarga do que isso, e em breve você terá strings muito maiores que 1600 bytes. E tudo isso com a suposição de codificação de caracteres de 1 byte.

Se você precisar indexar as amostras, os requisitos de dados crescerão ainda mais desproporcionalmente em relação a strings, porque um índice de string é muito mais caro em termos de armazenamento do que um índice de coluna de ponto flutuante.

E, claro, se suas amostras começarem a adicionar mais dígitos, o armazenamento de dados aumentará ainda mais. 39281.3392810 não será armazenável em 8 bytes como uma string, mesmo na melhor das hipóteses.

E se os dados forem serializados, o banco de dados não poderá manipular. Você não pode classificar as amostras, fazer qualquer tipo de operação matemática nelas, o banco de dados nem sabe que são números!

Para ser honesto, porém, o armazenamento é ridiculamente barato hoje em dia, você pode comprar várias unidades de TB por pequenas quantias. O armazenamento é realmente tão crítico? A menos que você tenha centenas de milhões de registros, duvido que seja.

Você pode querer conferir um livro chamado SQL Antipatterns