SQL vs NoSQL — Database

SQL vs NoSQL Tidak ada "yang terbaik" — pilihan bergantung pada kebutuhan spesifik aplikasi. SQL (Relational Database) Schema tetap — struktur tabel…

SQL database (relational) menyimpan data di tabel dengan schema tetap, menghubungkannya lewat id, dan menjamin transaksi ACID. NoSQL adalah keluarga database yang bukan tabel relational: document (MongoDB), key-value (Redis), graph, dan lainnya. Gak ada yang "terbaik". Yang menentukan adalah pola akses: pertanyaan apa yang paling sering ditanyakan aplikasimu, dan perubahan apa yang paling sering ditulisnya. Bayangin dua cara menyimpan arsip Kedai Senja: buku besar dengan kolom-kolom yang saling merujuk nomor (SQL), atau satu map lengkap per pesanan (document). Buku besar enak untuk merekap, map enak untuk mengambil satu pesanan utuh.

🧪 Tebakan cepat: Budi sudah punya 40 pesanan, lalu ganti nama. Di SQL, berapa baris yang harus di-UPDATE? Di MongoDB yang menyalin nama pembeli ke setiap dokumen pesanan, berapa dokumen? Tebak dulu, jawabannya ada di bagian "Mengubah data: Budi ganti nama".

Satu fitur, dua model

Fiturnya: riwayat pesanan Kedai Senja, dengan data yang sama seperti sepanjang track ini. Di SQL, datanya tersebar di empat tabel: customers, orders, order_items dan products, dan setiap fakta disimpan sekali. Di document (MongoDB), tiap pesanan adalah satu dokumen yang berisi nama pembeli dan item-itemnya:

{ _id: 1, customer: { _id: 1, name: 'Budi' },
  items: [ { product: 'Kopi Susu', price: 18000, qty: 2 },
           { product: 'Roti Bakar', price: 20000, qty: 1 } ] }

Lab di halaman ini menjalankan empat pola akses ke kedua model: SQL-nya di SQLite sungguhan, dokumennya dengan simulasi MongoDB.

Membaca satu pesanan

Halaman "pesanan #1" butuh pembeli dan semua itemnya:

SQL Document
Perintah 1 query dengan 3 JOIN db.orders.findOne({ _id: 1 })
Yang dibaca 6 baris dari 4 tabel 1 dokumen

Untuk "ambil satu benda utuh", document unggul: semuanya sudah ada di satu tempat.

Laporan lintas data

"Produk apa yang paling laku?" melintasi semua pesanan. Di SQL, ini satu GROUP BY:

SELECT p.name, SUM(oi.qty) AS terjual
FROM order_items oi
JOIN products p ON p.id = oi.product_id
GROUP BY p.id, p.name
ORDER BY terjual DESC, p.name;
name terjual
Kopi Susu 3
Kopi Susu Aren 1
Roti Bakar 1
Teh Tarik 1

Di document, perlu aggregation pipeline yang membongkar array items di semua dokumen ($unwind), mengelompokkan ($group), lalu mengurutkan ($sort). Bisa, tapi pertanyaan lintas data dan JOIN adalah rumahnya SQL.

Mengubah data: Budi ganti nama

UPDATE customers SET name = 'Budi Santoso' WHERE id = 1;

Di SQL, nama Budi cuma tersimpan di satu baris customers. 1 baris berubah, dan ke-40 pesanannya ikut menampilkan nama baru lewat JOIN. Di document, nama itu disalin ke setiap pesanan, jadi updateMany harus mengubah 40 dokumen. Itu jawaban tebakannya.

Ada masalah kedua. Di MongoDB, perubahan satu dokumen selalu atomic, tapi updateMany sebagai satu kesatuan tidak. Kalau server mati di tengah jalan, sebagian dokumen sudah bernama Budi Santoso dan sisanya masih Budi. Di SQL, perubahan di dalam transaksi berhasil semua atau batal semua: transaksi yang belum COMMIT dibuang saat server hidup lagi. MongoDB 4.0 ke atas juga punya transaksi multi-dokumen, tapi lebih mahal dan harus kamu pasang sendiri.

Mengubah bentuk data

Kedai Senja mau menambah catatan ("kurang manis") ke pesanan.

Schema fleksibel memang lebih cepat di awal. Bentuk datanya tetap ada, cuma pindah dari database ke kode aplikasi.

Konsistensi: ACID dan eventual consistency

ACID adalah janji transaksi di SQL database:

Transaksi ACID dan JOIN antar tabel adalah fitur inti SQL database. Makanya e-commerce dengan transaksi keuangan memakai SQL: uang yang hilang setengah jalan gak bisa diterima.

Banyak NoSQL memilih model BASE (Basically Available, Soft state, Eventually consistent). Datanya disalin ke beberapa server (node). Eventual consistency artinya setelah sebuah tulisan, data di semua node akan sama setelah beberapa waktu, bukan langsung:

waktu node A node B
10:00:00,000 Siti menulis like ke-101 masih 100
10:00:00,050 101 Budi membaca: 100
10:00:00,300 101 101, sudah sama

Untuk jumlah like, telat sepersekian detik gak masalah. Untuk saldo, masalah besar.

Memilih berdasarkan pola akses

Kebutuhanmu Pilihan
ACID, transaksi, relasi kompleks, e-commerce, banking SQL
schema fleksibel, data yang bentuknya beda-beda NoSQL (document)
horizontal scaling: menambah server, bukan memperbesar satu server NoSQL
real-time dan caching: counter live, session, cache NoSQL (key-value seperti Redis)

SQL database umumnya membesar secara vertical (server lebih besar) plus replica untuk baca. Banyak NoSQL dirancang untuk horizontal: data dibagi ke banyak server (sharding). Aplikasi nyata sering memakai keduanya (polyglot persistence): Kedai Senja menyimpan pesanan di PostgreSQL, cache dan session di Redis. Kalau ragu, mulai dari SQL.

⚠️ Jebakan yang sering ketemu

TL;DR: SQL menyimpan setiap fakta sekali di tabel yang saling menunjuk id, kuat di JOIN, laporan lintas data, dan transaksi ACID (Atomicity, Consistency, Isolation, Durability), jadi dipakai untuk e-commerce dan keuangan. NoSQL (document, key-value, graph) memberi schema fleksibel, baca satu benda utuh dengan cepat, dan horizontal scaling, dengan bayaran data yang disalin dan sering eventual consistency: semua node sama setelah beberapa waktu, bukan langsung. Budi ganti nama: SQL 1 baris, document sebanyak pesanannya. Pilih berdasarkan pola akses, bukan tren: ACID, transaksi, relasi kompleks, e-commerce ke SQL; schema fleksibel, horizontal scaling, real-time dan caching ke NoSQL; sering keduanya sekaligus.

Yang akan kamu pelajari