まず第一に、あなたは本当にそれをしたくありません。 RDBMSの列は、1つの情報のみが含まれているという点で、アトミックであることが意図されています。 1つの列に複数のデータを格納しようとすると、第一正規形に違反します。
どうしても必要な場合は、データを単一のデータ項目（通常は文字列）として保存できる形式に変換する必要があります。 PHPのserialize（）メカニズム、XML解析（データがドキュメントツリーである場合）、json_encode（）などを使用できます。
しかし、どのようにしてそのようなデータを効果的にクエリしますか？答えはできません。
また、他の誰かが後日あなたのプロジェクトを引き継ぐ場合、データベース内のシリアル化されたデータを操作するのは恐ろしいので、あなたは本当に彼らを苛立たせるでしょう。私はそのようなプロジェクトを継承しているので知っています。
私はあなたが本当にそれをしたくないと言いましたか？アトミック行の観点からより簡単に格納できるように、設計を再考する必要があります。たとえば、このデータには別のテーブルを使用し、外部キーを使用してデータをマスターレコードに関連付けます。それらは、理由からリレーショナルデータベースと呼ばれています。
更新 ：データストレージの要件について質問されました。たとえば、ストレージの観点から1行の方が安いかどうかなどです。答えは、通常はそうではなく、答えが「はい」の場合、あなたが支払う価格は支払う価値がないということです。
2列の依存テーブル（サンプルが属するレコードの外部キー用に1列、単一サンプル用に1列）を使用する場合、各列には最悪の場合16バイトが必要になります（longintキー列の場合は8バイト、8バイト）。倍精度浮動小数点数の場合）。 1600バイトの100レコードの場合（dbオーバーヘッドを無視）。
シリアル化された文字列の場合、最良の場合、文字列の文字ごとに1バイトを格納します。文字列の長さはわかりませんが、小数点以下2桁しかない、偶然の一致によってすべての保存データを含む100サンプルを想定すると、すべて10000.00から99999.99の間になります。サンプルあたり8バイトを再確認します。この場合、節約できるのは外部キーのオーバーヘッドだけなので、必要なストレージの量は800バイトになります。
もちろん、これは多くの仮定に基づいています。たとえば、文字エンコードは常に1文字あたり1バイトであり、サンプルを構成する文字列は8文字を超えることはありません。
ただし、もちろん、データのシリアル化に使用するメカニズムにはオーバーヘッドもあります。最も単純な方法であるCSVは、すべてのサンプルの間にコンマを追加することを意味します。これにより、格納されている文字列にn-1バイトが追加されます。したがって、上記の例は899バイトになり、これが最も単純なエンコード方式です。 JSON、XML、さらにはPHPのシリアル化でさえ、これよりも多くのオーバーヘッド文字が追加され、まもなく1600バイトよりもはるかに長い文字列が作成されます。そして、これはすべて、1バイトの文字エンコードを前提としています。
サンプルにインデックスを付ける必要がある場合、文字列インデックスは浮動小数点列インデックスよりもストレージの点ではるかに高価であるため、データ要件は文字列に対してさらに不均衡に増大します。
そしてもちろん、サンプルがさらに桁を追加し始めると、データストレージはさらに増加します。 39281.3392810は、最良の場合でも、文字列として8バイトで保存することはできません。
また、データがシリアル化されている場合、データベースは操作できません。サンプルを並べ替えたり、サンプルに対してあらゆる種類の数学演算を実行したりすることはできません。データベースは、サンプルが数値であることさえ認識していません。
正直なところ、最近のストレージは途方もなく安いので、少額で複数のTBドライブを購入できます。ストレージは本当に重要ですか？あなたが何億ものレコードを持っていない限り、私はそれがそうであるとは思えません。
SQLアンチパターンと呼ばれる本をチェックすることをお勧めします