TL;DR
Memecah string di SQL berarti ngubah satu kolom teks berpemisah, misalnya 'apel,jeruk,mangga', jadi beberapa baris terpisah. Di PostgreSQL, cara paling gampang pakai string_to_table atau unnest(string_to_array(...)). Di SQL Server pakai STRING_SPLIT dengan CROSS APPLY, dan di MySQL 8 pakai recursive CTE atau JSON_TABLE. Ini kebalikan dari STRING_AGG yang justru nggabungin baris jadi satu teks.
Memecah string di SQL berarti ngubah satu kolom teks berpemisah, misalnya 'apel,jeruk,mangga', jadi beberapa baris terpisah biar tiap nilai bisa dihitung dan disaring sendiri.
Data model kayak ini sering muncul dari kolom tag, kategori, atau daftar produk yang dijejalin ke satu sel. Selama masih nyatu, kamu susah ngitung atau nge-filter per nilai. Setelah dipecah, tiap nilai jadi baris yang gampang diolah.
Di artikel ini kamu bakal belajar cara mecah string di PostgreSQL, SQL Server, dan MySQL, plus contoh nyata dari data produk UMKM.
Nyimpen banyak nilai dalam satu sel, dipisah koma, ngelanggar prinsip data yang rapi. Kolom kayak gini bikin kamu nggak bisa JOIN, GROUP BY, atau filter per nilai dengan bener. Mecahnya jadi baris ngembaliin data ke bentuk yang bisa dianalisa.
Prinsip nyimpen satu nilai per sel ini bagian dari normalisasi data. Operasi mecah string ini kebalikan persis dari STRING_AGG yang nggabungin baris jadi satu teks. Satu misahin, satu nyatuin.
PostgreSQL punya beberapa cara. Yang paling ringkas sejak versi 14 adalah string_to_table, yang langsung ngubah teks berpemisah jadi kumpulan baris.
SELECT p.id, trim(t) AS tag
FROM produk p, string_to_table(p.tags, ',') AS t;
Fungsi trim di sini penting buat ngilangin spasi di sekitar tiap nilai, soalnya 'apel, jeruk' sering punya spasi setelah koma. Tanpa trim, tag-nya jadi ' jeruk' dengan spasi di depan.
Buat PostgreSQL versi lama yang belum punya string_to_table, pakai kombinasi unnest dan string_to_array yang hasilnya sama.
SELECT p.id, trim(t) AS tag
FROM produk p
CROSS JOIN unnest(string_to_array(p.tags, ',')) AS t;
Kalau pemisahnya nggak konsisten, misalnya kadang pakai spasi kadang nggak, pakai regexp_split_to_table biar lebih tahan variasi.
SELECT id, regexp_split_to_table(tags, '\s*,\s*') AS tag
FROM produk;
SQL Server punya fungsi bawaan STRING_SPLIT sejak versi 2016. Pasangin dengan CROSS APPLY biar tiap baris asal dipecah jadi banyak baris.
SELECT p.id, s.value AS tag
FROM produk p
CROSS APPLY STRING_SPLIT(p.tags, ',') AS s;
MySQL agak ribet karena nggak punya fungsi split bawaan sampai versi terbaru. Di MySQL 8, cara paling umum pakai recursive CTE atau ubah teksnya jadi JSON dulu lalu pakai JSON_TABLE. Kalau datamu banyak dan sering dipecah, mendingan benerin desain tabelnya di awal daripada mecah tiap query.
Aku pegang tabel produk toko_berkah dengan 240 baris. Ada kolom tags yang isinya kategori dipisah koma, kayak 'sembako, promo, laris'. Aku mau tau tag mana yang paling sering nempel di produk.
SELECT trim(t) AS tag, COUNT(*) AS jumlah
FROM produk p, string_to_table(p.tags, ',') AS t
GROUP BY trim(t)
ORDER BY jumlah DESC;
Setelah dipecah, 240 produk berubah jadi 612 baris tag. Rata-rata tiap produk punya 2,55 tag. Hasilnya nunjukin tag 'sembako' nempel di 41% produk (98 dari 240), disusul 'promo' di 27%. Tanpa mecah string dulu, angka ini mustahil dihitung karena semua tag ketumpuk di satu sel.
Dari sini aku bisa lanjut, misalnya cari produk yang punya tag 'promo' tapi bukan 'laris', buat evaluasi promo yang nggak jalan.
Pertanyaan yang sering muncul soal memecah string di SQL.
Cara paling ringkas sejak PostgreSQL 14 adalah string_to_table, yang langsung ngubah teks berpemisah jadi baris. Buat versi lama, pakai unnest dipadu string_to_array yang hasilnya sama. Kalau pemisahmu bervariasi, misalnya kadang ada spasi kadang nggak, pakai regexp_split_to_table yang nerima pola regex. Ketiganya ngerjain tugas yang sama, tinggal pilih sesuai versi PostgreSQL dan seberapa konsisten pemisah datamu.
Ini karena datamu ditulis dengan spasi setelah koma, misalnya 'apel, jeruk, mangga'. Waktu dipecah pakai koma sebagai pemisah, spasi setelah koma ikut kebawa jadi bagian nilai, jadi hasilnya ' jeruk' bukan 'jeruk'. Solusinya bungkus tiap nilai hasil dengan fungsi trim buat ngilangin spasi di kedua ujung. Ini penting banget kalau kamu mau GROUP BY, karena ' jeruk' dan 'jeruk' bakal dihitung sebagai dua nilai berbeda.
MySQL memang nggak punya fungsi split sebawaan PostgreSQL atau SQL Server. Di MySQL 8, dua cara paling umum adalah pakai recursive CTE buat ngiterasi tiap bagian teks, atau ubah dulu teksnya jadi format JSON array lalu pakai JSON_TABLE buat mecahnya. Keduanya agak panjang. Kalau kamu sering butuh mecah kolom yang sama, lebih hemat benerin desain tabelnya dengan nyimpen nilai di tabel terpisah sejak awal.
Keduanya operasi yang berlawanan arah. STRING_AGG dan GROUP_CONCAT nggabungin banyak baris jadi satu teks berpemisah, misalnya banyak produk jadi satu daftar. Memecah string ngerjain kebalikannya: ngubah satu teks berpemisah balik jadi banyak baris. Kamu bisa pakai keduanya bergantian sesuai kebutuhan, misalnya gabungin buat tampilan laporan, lalu pecah lagi kalau mau dianalisa per nilai. Paham keduanya bikin kamu fleksibel ngolah data teks.
Memecah string ngubah data yang ketumpuk jadi baris yang bisa dianalisa. Di PostgreSQL pakai string_to_table atau unnest, di SQL Server pakai STRING_SPLIT dengan CROSS APPLY. Jangan lupa trim spasi tiap nilai, dan saring baris kosong kalau perlu.
Kalau kolom berpemisah ini sering kamu olah, pertimbangkan benerin desain tabelnya sejak awal. Mau operasi kebalikannya? Baca STRING_AGG dan GROUP_CONCAT. Buat kasus di spreadsheet, ada fungsi SPLIT Google Sheets. Detail fungsinya ada di dokumentasi PostgreSQL string functions. Mau latihan query SQL? Kulik di NgulikSQL.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Mau daftar produk per order jadi satu sel dipisah koma, bukan puluhan baris? STRING_AGG di PostgreSQL dan GROUP_CONCAT di MySQL ngerjain itu dalam satu GROUP BY.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.