N+1 Query Problem: Kode ORM Siti Kelihatan Rapi, Tapi Servernya Mati

Bayangin Siti Nampilin Daftar Artikel Blog...

Bayangin Siti bikin halaman *Blog* pakai Node.js dan ORM Prisma. Dia mau nampilin 10 artikel terbaru beserta nama penulisnya. Kode JavaScript Siti sangat singkat dan elegan:

const articles = await db.article.findMany({ limit: 10 });
for (let article of articles) {
  const author = await db.user.findUnique({ where: { id: article.authorId } });
  console.log(author.name);
}

Waktu diuji coba di laptopnya, 10 artikel muncul dalam sekejap. Tapi saat *website*-nya rilis dan ada 100 artikel, *loading* halamannya tiba-tiba memakan waktu 10 detik dan server MySQL-nya CPU-nya tembus 100%!

Masalahnya: N+1 Query Problem

Siti tidak sadar bahwa kode for-loop yang ia buat adalah sebuah Senjata Pemusnah Massal untuk database. Mari kita hitung apa yang terjadi di belakang layar:

1. Sistem menembak MySQL 1 kali untuk mengambil daftar 100 artikel.
2. Sistem masuk ke dalam Looping, dan menembak MySQL 100 KALI BERTURUT-TURUT hanya untuk menanyakan nama penulis satu per satu!
3. Total MySQL ditembak sebanyak 101 kali (N + 1) hanya untuk memuat satu halaman *website*! Ini sangat boros koneksi jaringan (Network Latency).

Nah, Di Sinilah 'Eager Loading' Masuk!

Database SQL itu dirancang untuk bekerja secara borongan (Bulk), bukan dicicil satu-satu. Untuk menyelesaikan ini, Siti harus menggunakan teknik Eager Loading (JOIN).

• Siti menghapus kode *looping*-nya, dan mengubah query pertamanya dengan menambahkan kata kunci sakti: include: { author: true }.
• Kini, ORM Prisma akan menyatukan pertanyaannya ke MySQL: "Hei MySQL, tolong carikan 100 artikel, DAN SEKALIAN tempelin nama penulisnya ya di sebelahnya!"
• MySQL merajutnya menggunakan SQL JOIN, dan mengembalikan semuanya dalam HANYA 1 KALI TEMBAKAN QUERY! Waktu loading pun kembali menjadi 0.01 detik.

Intinya: Jangan pernah meletakkan *Query Database* di dalam sebuah perulangan (For-Loop / Map). Itu adalah dosa mematikan di dunia Backend!