Pernah nggak kamu lagi enak-enak nulis kode Laravel, terus tiba-tiba mikir: "Eh, ini harusnya pakai Eloquent atau Query Builder ya?" Kalau pernah — selamat, kamu nggak sendirian! Ini adalah salah satu dilema paling umum yang dihadapi developer PHP yang baru terjun ke dunia migration Laravel dan ORM. Dua tools ini sama-sama powerful, tapi punya karakter yang beda banget. Artikel ke-13 dari seri 50 Artikel Belajar Laravel ini hadir untuk tuntas menjawab pertanyaan itu, lengkap dengan perbandingan kode, tabel perbedaan, dan panduan kapan harus pakai yang mana. Siap? Yuk mulai!
Query Builder adalah antarmuka berbasis method-chaining untuk membangun query SQL secara fluent tanpa model. Kamu bekerja langsung dengan nama tabel.
Eloquent ORM adalah lapisan abstraksi di atas Query Builder yang menghubungkan tabel database ke sebuah Model PHP. Setiap baris data jadi sebuah objek dengan method, relasi, dan event bawaan.
Analogi Kehidupan Nyata: Migration Laravel Sebagai Fondasi
Sebelum bicara Query Builder vs Eloquent, kita perlu sepakat dulu soal fondasi. Bayangkan kamu lagi bangun rumah. Migration Laravel adalah blueprint arsitektur-nya — mendefinisikan ada berapa kamar (kolom), dinding apa yang dipakai (tipe data), dan mana pintu utamanya (primary key). Tanpa migration yang solid, kamu nggak bisa membangun sistem query yang efisien.
Nah, setelah rumah jadi (tabel sudah ter-migrate), barulah kamu mulai "hidup di dalamnya". Di sinilah Query Builder dan Eloquent masuk. Keduanya adalah cara kamu berinteraksi dengan rumah tersebut — tapi dengan gaya yang berbeda.
Anggap Query Builder seperti mekanik handal yang bawa toolbox lengkap. Dia bisa kerja di bengkel mana saja, langsung ke baut dan mur. Sementara Eloquent lebih seperti asisten pribadi cerdas yang sudah hafal seluk-beluk satu bengkel tertentu — lebih nyaman diajak ngobrol, tapi butuh "orientasi" (model) lebih dulu.
Eloquent ORM di Laravel sebenarnya membangun Query Builder di belakang layar. Artinya, setiap query Eloquent yang kamu tulis pada akhirnya dikonversi ke Query Builder sebelum dieksekusi ke database. Eloquent = Query Builder + lapisan abstraksi yang manis!
Perbandingan Kode: Query Builder vs Eloquent dalam Migration Laravel
Oke, cukup teorinya. Mari kita lihat perbedaannya langsung dari kode. Kita anggap punya tabel users yang sudah dibuat via migration Laravel.
Buat Migration Tabel Users
Jalankan perintah ini di terminal untuk membuat file migration baru.
php artisan make:migration create_users_table
Isi File Migration
Buka file hasil generate di folder database/migrations, lalu isi seperti ini:
Schema::create('users', function (Blueprint $table) { $table->id(); $table->string('name'); $table->string('email')->unique(); $table->timestamps(); });
Query dengan Query Builder
Akses tabel langsung via facade DB. Tidak perlu Model sama sekali.
// Ambil semua user aktif, urutkan by name $users = DB::table('users') ->where('is_active', true) ->orderBy('name', 'asc') ->get(); // Insert data baru DB::table('users')->insert([ 'name' => 'Budi Santoso', 'email' => 'budi@example.com', ]);
Query yang Sama dengan Eloquent
Pastikan sudah ada Model User yang terhubung ke tabel users.
// Ambil semua user aktif, urutkan by name $users = User::where('is_active', true) ->orderBy('name', 'asc') ->get(); // Insert data baru (lebih ekspresif!) User::create([ 'name' => 'Budi Santoso', 'email' => 'budi@example.com', ]);
Untuk menggunakan User::create(), pastikan kamu sudah mendefinisikan properti $fillable di Model User. Ini adalah lapisan keamanan Laravel untuk mencegah mass assignment vulnerability.
Kapan Pakai Migration Laravel + Query Builder vs Eloquent?
Ini pertanyaan jutaan dolar. Jawabannya: tergantung konteks. Tapi tenang, ada panduan praktisnya.
Pilih Query Builder jika...
- Query melibatkan banyak JOIN kompleks
- Operasi bulk update/delete jutaan baris
- Membuat laporan atau data aggregation
- Tidak ada model yang relevan (tabel log, pivot)
- Butuh performa maksimal
Pilih Eloquent jika...
- Mengerjakan fitur CRUD standar
- Butuh fitur relasi (hasMany, belongsTo)
- Ingin memanfaatkan Model Events
- Kode perlu mudah dibaca tim
- Pakai fitur seperti Scopes atau Mutators
Di proyek Laravel yang mature, kamu akan sering mencampurkan keduanya. Misalnya: gunakan Eloquent untuk CRUD di Controller, tapi beralih ke Query Builder untuk generate laporan besar di bagian reporting. Ini bukan hal yang tabu — ini justru pendekatan yang disarankan para senior developer!
Tips Praktis & Jebakan yang Wajib Kamu Hindari
Setelah menguasai dasar migration Laravel dan keduanya, ada beberapa jebakan klasik yang sering menimpa developer baru. Yuk, kita antisipasi dari sekarang!
Jebakan terbesar Eloquent adalah N+1 Query Problem. Saat kamu looping relasi tanpa eager loading, Laravel akan menembak query ke database sebanyak N kali. Solusi: selalu gunakan with() saat mengakses relasi. Contoh: User::with('posts')->get()
Jangan jalankan php artisan migrate:fresh di production! Perintah ini akan menghapus semua tabel dan data. Gunakan hanya di development. Di production, gunakan migrate biasa atau migrate:rollback dengan hati-hati.
💻 Contoh Nyata: Kombinasi Keduanya dalam Satu Controller
class UserController extends Controller { // Eloquent: CRUD standar dengan relasi public function index() { $users = User::with('posts')->paginate(15); return view('users.index', compact('users')); } // Query Builder: Laporan performa (lebih cepat) public function report() { $stats = DB::table('users') ->selectRaw('DATE(created_at) as date, COUNT(*) as total') ->groupBy('date') ->orderBy('date', 'desc') ->limit(30) ->get(); return response()->json($stats); } }
No comments:
Post a Comment