Sebelum melangkah ke instalasi, mari kita pastikan MySQL adalah alat yang tepat untuk kebutuhan kita. MySQL unggul pada data terstruktur yang berbentuk tabel, berelasi antar satu sama lain, dan membutuhkan konsistensi transaksi yang ketat. Pada Chapter ini kita petakan use case khas MySQL, mencoba contoh database inventaris kecil sebagai gambaran nyata, dan melihat dengan jujur batas-batasnya — kapan jenis database lain menjadi pilihan yang lebih pas.
Skenario Klasik MySQL #
Use case MySQL paling banyak dijumpai pada aplikasi yang datanya berbentuk entitas saling terhubung. Beberapa skenario klasik berikut akan terasa akrab:
- Aplikasi web dan API — akun user, konten, sesi, dan log aktivitas; kombinasi LAMP (Linux, Apache, MySQL, PHP) menjadi pola klasiknya.
- Toko online — katalog produk, keranjang, pesanan, dan catatan pembayaran yang harus konsisten satu sama lain.
- CMS dan blog — WordPress, CMS paling banyak dipakai di dunia, dibangun di atas MySQL.
- Aplikasi bisnis internal — inventaris gudang, pembukuan keuangan, data karyawan, dan penjadwalan.
- Backend aplikasi mobile — API yang menyajikan data pengguna, pesan, dan transaksi.
- Pelaporan ringan hingga menengah — rekap penjualan dan agregasi data lewat
GROUP BYdan fungsi agregat.
Benang merah seluruh skenario di atas sama: datanya punya struktur yang jelas, entitasnya saling berelasi (produk dengan pesanan, user dengan konten), dan perubahan data harus konsisten — uang bertambah tepat ketika stok berkurang. Kebutuhan semacam ini adalah wilayah terkuat MySQL.
Mengapa MySQL Sering Dipilih #
Alasan popularitas MySQL bukan kebetulan. MySQL sudah berkembang lebih dari tiga dekade sehingga kompatibilitas, dokumentasi, dan komunitasnya sangat matang. Sebagian besar penyedia hosting menyediakan MySQL siap pakai, dan connector resmi tersedia untuk hampir semua bahasa pemrograman populer — dari PHP dan Python sampai Go dan Java.
Dari sisi biaya dan operasional, edisi Community gratis dengan lisensi open source. Dari sisi skalabilitas, replikasi bawaan memungkinkan data disalin ke beberapa server sehingga beban baca tinggi dapat dibagi. Dan dari sisi karier, SQL yang kita pelajari di MySQL dapat dipakai lintas database relasional lain. Kombinasi matang, murah, terdokumentasi, dan mudah diskalakan inilah yang membuat MySQL tetap jadi pilihan default banyak tim.
Contoh Mini: Database Inventaris #
Kita tutup pemetaan teori dengan contoh kecil yang realistis: inventaris toko alat tulis. Contoh ini sekaligus menjadi pratinjau bentuk akhir data aplikasi nyata yang akan kita bangun sepanjang course:
CREATE DATABASE belajar_inventaris;Output yang Dihasilkan:
Query OK, 1 row affected (0.00 sec)Table barang menyimpan setiap item beserta kategori, harga, dan stoknya:
USE belajar_inventaris;
CREATE TABLE barang (
id INT PRIMARY KEY,
nama VARCHAR(60),
kategori VARCHAR(30),
harga DECIMAL(10,2),
stok INT
);Output yang Dihasilkan:
Database changed
Query OK, 0 rows affected (0.00 sec)Kita isi dengan empat barang contoh:
USE belajar_inventaris;
INSERT INTO barang (id, nama, kategori, harga, stok) VALUES
(1, 'Pensil Kayu', 'alat tulis', 3500.00, 120),
(2, 'Buku Tulis 58 Halaman', 'alat tulis', 5000.00, 85),
(3, 'Tumbler Stainless', 'perlengkapan', 78000.00, 15),
(4, 'Payung Lipat', 'perlengkapan', 45000.00, 22);Output yang Dihasilkan:
Database changed
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0Query harian paling dasar pada aplikasi seperti ini adalah menyaring dan mengurutkan. Kita ambil daftar barang kategori alat tulis dari yang termurah:
USE belajar_inventaris;
SELECT nama, harga FROM barang
WHERE kategori = 'alat tulis'
ORDER BY harga;Output yang Dihasilkan:
Database changed
+-----------------------+---------+
| nama | harga |
+-----------------------+---------+
| Pensil Kayu | 3500.00 |
| Buku Tulis 58 Halaman | 5000.00 |
+-----------------------+---------+
2 rows in set (0.00 sec)Untuk laporan ringkas, MySQL menghitung agregat langsung di dalam server — jumlah barang dan harga rata-rata per kategori:
USE belajar_inventaris;
SELECT kategori, COUNT(*) AS jumlah_barang, AVG(harga) AS harga_rata
FROM barang
GROUP BY kategori
ORDER BY kategori;Output yang Dihasilkan:
Database changed
+--------------+---------------+--------------+
| kategori | jumlah_barang | harga_rata |
+--------------+---------------+--------------+
| alat tulis | 2 | 4250.000000 |
| perlengkapan | 2 | 61500.000000 |
+--------------+---------------+--------------+
2 rows in set (0.00 sec)Query di atas bekerja tiga tahap. Klausa GROUP BY kategori mengelompokkan baris berdasarkan kategorinya, fungsi COUNT(*) menghitung anggota tiap kelompok, dan AVG(harga) menghitung nilai rata-rata kolom harga tiap kelompok. Klausa ORDER BY kategori menjaga urutan kelompok tetap alfabetis. Fungsi agregat akan kita bahas tuntas pada bagian fungsi agregat — untuk sekarang cukup terlihat bahwa pelaporan tidak memerlukan alat terpisah dari database.
Dukungan JSON untuk Data Semi-Terstruktur #
Tidak semua data cocok dipaksa ke dalam tabel. MySQL menjawabnya dengan tipe data JSON: kolom dapat menyimpan dokumen semi-terstruktur dan query tetap dapat membaca bagian dalamnya. Sebagai gambaran, fungsi JSON_EXTRACT mengambil anggota tertentu dari sebuah dokumen JSON:
SELECT JSON_EXTRACT('{"nama": "Budi", "kota": "Bandung"}', '$.kota') AS kota;Output yang Dihasilkan:
+-----------+
| kota |
+-----------+
| "Bandung" |
+-----------+
1 row in set (0.00 sec)Path '$.kota' menunjuk anggota bernama kota pada dokumen JSON, dan hasilnya tampil sebagai teks JSON lengkap dengan tanda kutipnya. Dukungan JSON memudahkan MySQL menyimpan data fleksibel — atribut produk yang berbeda-beda, misalnya — tanpa meninggalkan dunia relational. Namun bila aplikasi kita didominasi dokumen bersarang tanpa skema tetap, document database seperti MongoDB memang dirancang khusus untuk pola tersebut.
Contoh pada chapter ini sudah selesai dipakai, jadi kita hapus database latihan belajar_inventaris:
DROP DATABASE belajar_inventaris;Output yang Dihasilkan:
Query OK, 1 row affected (0.00 sec)Kapan MySQL Kurang Cocok #
Kejujuran teknis menuntut kita mengakui batas. Beberapa pola kebutuhan berikut lebih baik dilayani jenis database lain:
| Kebutuhan | Alternatif yang lebih pas |
|---|---|
| Cache key-value berlatensi sangat rendah | In-memory store seperti Redis |
| Dokumen bersarang tanpa skema tetap | Document store seperti MongoDB |
| Data time-series sensor dalam skala sangat besar | Database time-series |
| Penelusuran relasi graph berlapis-lapis | Graph database |
| Pencarian teks full-text berbobot kompleks | Search engine khusus |
Tabel di atas bukan larangan mutlak. MySQL memiliki fulltext index untuk pencarian teks, tipe JSON untuk dokumen, dan tetap bisa dipakai untuk kebutuhan ringan pada tiap baris tabel tersebut. Patokannya adalah pola akses dominan: bila 90% beban aplikasi adalah cache, Redis memang lebih tepat daripada MySQL; bila inti aplikasi adalah data transaksional yang berelasi, MySQL adalah pilihan kuatnya.
Referensi #
- MySQL 8.4 Reference Manual — MySQL
- The JSON Data Type — MySQL 8.4 Reference Manual
- Replication — MySQL 8.4 Reference Manual
MySQL terbukti tepat untuk aplikasi berdata relasional — dan kita baru saja melihat wujud nyatanya lewat database inventaris kecil. Pemahaman konsep sudah lengkap; saatnya menyiapkan mesin belajar kita. Bagian berikutnya memandu instalasi MySQL mulai dari memilih paket, menjalankan server pertama, sampai tersambung dari terminal.