Di era vibe coding, godaan untuk menyerahkan semuanya ke AI semakin besar. UI? AI. Business logic? AI. Database schema? AI juga. Tinggal prompt, tunggu, dan terima hasilnya.
Untuk UI dan helper function, pendekatan itu bisa jalan. Kalau hasilnya salah, kamu langsung lihat di browser dan perbaiki. Tapi untuk database schema, ceritanya sangat berbeda. Kalau fondasinya salah, semua kode yang dibangun di atasnya juga akan salah. Dan memperbaiki schema di tengah development jauh lebih mahal daripada memperbaikinya di awal.
Schema Bukan Sekadar Tabel dan Kolom
Database schema itu berfungsi sebagai kontrak antara bisnis, aplikasi, dan developer. Setiap tabel, kolom, dan relasi di dalam schema mencerminkan keputusan produk yang sudah kamu buat.
Ambil contoh sederhana: sistem reservasi restoran. Di dokumen perencanaan, kamu sudah menentukan bahwa customer tidak perlu membuat akun dan booking cukup dilacak via booking reference. Keputusan bisnis ini harus tercermin di schema. Kalau kamu serahkan ke AI tanpa konteks ini, AI kemungkinan besar akan generate tabel users untuk customer, tabel sessions, dan seluruh flow autentikasi yang sebenarnya tidak kamu butuhkan.
Ini bukan hipotesis. Ini pattern yang konsisten terjadi.
Data Bicara: Kode AI Punya Masalah Struktural
Analisis longitudinal dari GitClear menemukan peningkatan duplikasi kode hingga 8 kali lipat di codebase yang menggunakan AI assistant. Sementara itu, kode yang di-refactor turun drastis. Artinya, AI tidak membangun struktur yang bersih. AI menumpuk kode baru di atas kode lama tanpa memikirkan bagaimana semuanya saling terhubung.
Untuk database schema, dampak ini bahkan lebih berbahaya. Schema yang tidak terstruktur dengan baik akan menyebabkan:
- Query yang lambat karena relasi dan index tidak dirancang dengan benar
- Data inconsistency karena constraint tidak diterapkan di level database
- Refactor yang menyakitkan karena perubahan satu tabel bisa berdampak ke seluruh aplikasi
Seorang analis industri bahkan memproyeksikan $1.5 triliun technical debt yang terakumulasi sampai 2027 dari kode AI yang strukturnya tidak dipikirkan matang. Schema yang buruk adalah kontributor utama technical debt semacam ini.
AI Butuh Arahan, Bukan Kebebasan Penuh
Ini bukan berarti AI tidak boleh dilibatkan sama sekali dalam proses desain schema. AI sangat membantu untuk:
- Generate DDL (Data Definition Language) dari draft entitas dan relasi yang sudah kamu definisikan
- Menyarankan index berdasarkan query pattern yang kamu jelaskan
- Mendeteksi inkonsistensi dalam naming convention atau tipe data
Tapi semua itu bekerja optimal kalau kamu sudah punya pemahaman sendiri tentang entitas utama, relasi antar tabel, dan constraint yang harus ada. Kamu yang mendefinisikan "apa yang harus ada", AI yang membantu menerjemahkannya menjadi SQL yang rapi.
Workflow yang lebih efektif terlihat seperti ini:
Step 1: Draft entitas dan relasi secara manual. Tanpa AI. Kamu tentukan tabel apa saja yang dibutuhkan, bagaimana mereka saling terhubung, dan constraint apa yang berlaku. Ini memaksa kamu berpikir tentang domain bisnis secara mendalam.
Step 2: Tulis prompt yang efektif untuk AI generate DDL. Dengan draft yang sudah jelas, prompt kamu jadi spesifik. AI tidak menebak, tapi menerjemahkan keputusan yang sudah kamu buat.
Step 3: Review dan refinement. Periksa relasi, tipe data, constraint, dan index. Pastikan semuanya sesuai dengan kebutuhan bisnis, bukan sekadar "secara teknis valid".
Prinsip yang Perlu Kamu Pegang
Ada beberapa prinsip desain schema yang sering diabaikan developer yang terlalu mengandalkan AI:
Mulai dari yang sederhana. Schema untuk MVP tidak perlu mencover semua kemungkinan masa depan. Mulai dari entitas yang benar-benar dibutuhkan sekarang. Kalau PRD kamu bilang "single branch", jangan buat tabel branches. Kalau MVP tidak butuh loyalty program, jangan buat tabel points.
Naming convention yang konsisten. snake_case untuk kolom, plural untuk nama tabel, pattern yang jelas untuk foreign key. Konsistensi ini terlihat sepele tapi sangat berpengaruh saat codebase membesar. AI yang kamu pakai nanti juga akan lebih mudah memahami schema yang konsisten.
Constraint di level database, bukan hanya di aplikasi. Unique constraint, foreign key, check constraint. Jangan bergantung hanya pada validasi di kode. Database adalah pertahanan terakhir terhadap data yang tidak valid.
Fondasi yang Kuat, Development yang Lancar
Developer yang meluangkan waktu mendesain schema sebelum coding akan merasakan dampaknya di seluruh fase development. AI yang kamu pakai selama coding akan menghasilkan kode yang lebih akurat karena schema-nya jelas. Migration berjalan mulus karena relasinya sudah dipikirkan. Dan yang paling penting: kamu tidak perlu refactor di tengah jalan karena "ternyata strukturnya salah dari awal".
Schema database adalah investasi. Waktu yang kamu habiskan di awal akan menghemat waktu berlipat-lipat di belakang.
Artikel ini diadaptasi dari buku "Mahir Vibe Coding: Dari Ide ke Sistem yang Terstruktur" yang membahas secara detail proses desain database schema sebelum development dimulai, lengkap dengan contoh studi kasus Restaurant Booking & Ordering System.
