Pertama, Anda benar-benar tidak ingin melakukan itu. Kolom dalam RDBMS dimaksudkan untuk menjadi atom, karena berisi satu dan hanya satu informasi. Mencoba menyimpan lebih dari satu bagian data dalam satu kolom merupakan pelanggaran terhadap bentuk normal pertama.
Jika Anda benar-benar harus melakukannya, maka Anda perlu mengubah data menjadi bentuk yang dapat disimpan sebagai satu item data, biasanya berupa string. Anda dapat menggunakan mekanisme serialize() PHP, parsing XML (jika data berupa pohon dokumen), json_encode(), dll.
Tetapi bagaimana Anda menanyakan data tersebut secara efektif? Jawabannya adalah Anda tidak bisa.
Juga, jika orang lain mengambil alih proyek Anda di kemudian hari, Anda benar-benar akan mengganggu mereka, karena data serial dalam database sangat buruk untuk dikerjakan. Saya tahu karena saya mewarisi proyek semacam itu.
Apakah saya menyebutkan Anda benar-benar tidak ingin melakukan itu? Anda perlu memikirkan kembali desain Anda sehingga dapat lebih mudah disimpan dalam bentuk baris atom. Gunakan tabel lain untuk data ini, misalnya, dan gunakan kunci asing untuk menghubungkannya dengan rekaman master. Mereka disebut database relasional karena suatu alasan.
PERBARUI :Saya pernah ditanya tentang persyaratan penyimpanan data, seperti apakah satu baris akan lebih murah dalam hal penyimpanan. Jawabannya adalah, dalam kasus umum tidak, dan dalam kasus di mana jawabannya adalah ya, harga yang Anda bayar tidak layak untuk dibayar.
Jika Anda menggunakan tabel dependen 2 kolom (1 kolom untuk kunci asing dari catatan yang dimiliki sampel, satu untuk sampel tunggal) maka setiap kolom akan membutuhkan paling buruk 16 byte (8 byte untuk kolom kunci longint, 8 byte untuk nomor floating point presisi ganda). Untuk 100 record, itu sama dengan 1600 byte (mengabaikan db overhead).
Untuk string serial, Anda menyimpan dalam kasus terbaik 1 byte per karakter dalam string. Anda tidak dapat mengetahui berapa lama string akan menjadi, tetapi jika kita mengasumsikan 100 sampel dengan semua data yang disimpan oleh beberapa kebetulan yang dibuat semua jatuh antara 10000.00 dan 99999.99 dengan hanya ada 2 digit setelah titik desimal, maka Anda ' kembali melihat 8 byte per sampel. Dalam hal ini, semua yang Anda simpan adalah overhead kunci asing, sehingga jumlah penyimpanan yang diperlukan adalah 800 byte.
Itu tentu saja didasarkan pada banyak asumsi, seperti pengkodean karakter selalu 1 byte per karakter, string yang membentuk sampel tidak pernah lebih dari 8 karakter, dll.
Tapi tentu saja ada juga overhead dari mekanisme apa pun yang Anda gunakan untuk membuat serial data. Metode paling sederhana, CSV, berarti menambahkan koma di antara setiap sampel. Itu menambahkan n-1 byte ke string yang disimpan. Jadi contoh di atas sekarang akan menjadi 899 byte, dan itu dengan skema pengkodean paling sederhana. JSON, XML, bahkan serialisasi PHP semuanya menambahkan lebih banyak karakter overhead dari ini, dan Anda akan segera memiliki string yang jauh lebih panjang dari 1600 byte. Dan semua ini dengan asumsi pengkodean karakter 1 byte.
Jika Anda perlu mengindeks sampel, persyaratan data akan tumbuh lebih tidak proporsional terhadap string, karena indeks string jauh lebih mahal dalam hal penyimpanan daripada indeks kolom floating point.
Dan tentu saja jika sampel Anda mulai menambahkan lebih banyak digit, penyimpanan data akan meningkat lebih jauh. 39281.3392810 tidak akan dapat disimpan dalam 8 byte sebagai string, bahkan dalam kasus terbaik.
Dan jika data diserialisasi, database tidak dapat dimanipulasi. Anda tidak dapat mengurutkan sampel, melakukan operasi matematika apa pun pada sampel tersebut, database bahkan tidak tahu bahwa itu adalah angka!
Sejujurnya, penyimpanan sangat murah akhir-akhir ini, Anda dapat membeli beberapa drive TB dengan jumlah kecil. Apakah penyimpanan benar-benar penting? Kecuali Anda memiliki ratusan juta catatan maka saya ragu itu.
Anda mungkin ingin membaca buku berjudul SQL Antipatterns
