Aplikasi modern semakin sering dituntut untuk mendukung berbagai mesin database tanpa memerlukan perubahan struktur di level aplikasi. Perpindahan dari MySQL ke PostgreSQL atau SQLite seharusnya cukup dengan mengganti driver, dialek, dan endpoint database — tanpa perlu menulis ulang skema.
Dalam pengembangan MagicAppBuilder, muncul satu pertanyaan arsitektural penting:
Bagaimana menjaga kompatibilitas struktur database lintas mesin tanpa memaksa developer melakukan perubahan skema setiap kali berganti database?
Solusinya bukan dengan menurunkan struktur ke “fitur paling minimal yang didukung semua database”.
Sebaliknya, kami memperlakukan SQLite secara berbeda — sebagai pembawa metadata (metadata carrier), bukan sebagai mesin validasi ketat.
Ide Utama
SQLite tidak memvalidasi panjang NVARCHAR(40) seperti MySQL atau PostgreSQL.
Contoh:
song_id NVARCHAR(40)
Di SQLite:
- Panjang tidak divalidasi
- Nilai tidak akan dipotong
- Secara internal diperlakukan seperti TEXT
Namun kami tetap menyimpan definisi NVARCHAR(40) di skema SQLite.
Mengapa?
Karena generator skema perlu menjaga intent struktur, bukan hanya perilaku runtime.
SQLite sebagai Database Development & Metadata
Dalam arsitektur kami, SQLite digunakan sebagai:
- Database development
- Database embedded
- Penyimpan metadata struktur yang kompatibel lintas dialek
SQLite tidak kami andalkan untuk enforcement constraint produksi yang ketat.
Pendekatan ini memungkinkan:
- Konsistensi definisi kolom antar database
- Informasi panjang field tetap terbaca oleh generator
- Tidak perlu refactor saat berpindah ke MySQL atau PostgreSQL
Ketika pengguna mengganti konfigurasi database dari SQLite ke MySQL atau PostgreSQL, aplikasi tidak membutuhkan perubahan struktur. Skema sudah portabel sejak awal.
Mengapa Tidak Menggunakan TEXT di SQLite?
Rekomendasi umum biasanya:
“Gunakan TEXT saja di SQLite.”
Secara teknis benar.
Namun secara arsitektural, ini membatasi.
Jika kita mengganti NVARCHAR(40) menjadi TEXT, maka kita kehilangan:
- Metadata panjang kolom
- Kesimetrian struktur antar dialek
- Konsistensi pembacaan oleh generator
Tujuan kami bukan mengoptimalkan sistem tipe SQLite, melainkan menjaga konsistensi struktur lintas database.
Strategi Lintas Dialek
Generator skema di MagicAppBuilder mengikuti prinsip berikut:
- Menjaga konsistensi definisi struktur.
- Memisahkan metadata struktur dari enforcement constraint.
- Menghasilkan SQL spesifik dialek jika diperlukan.
- Menghindari sintaks yang tidak portabel.
Contohnya, daripada membuat index inline di dalam CREATE TABLE, kami menghasilkan:
CREATE TABLE ...
;
CREATE INDEX ...
;
Pendekatan ini kompatibel dengan:
- MySQL
- PostgreSQL
- SQLite
- SQL Server
Trade-Off (Dan Mengapa Ini Disengaja)
Menggunakan NVARCHAR(40) di SQLite memang tidak akan memvalidasi panjang data. Itu adalah batasan yang kami sadari sepenuhnya.
Namun validasi dapat dialihkan ke:
- Validasi di level aplikasi
- Validator runtime
- Database produksi (MySQL / PostgreSQL)
Ini adalah trade-off arsitektural yang disengaja:
Kami memprioritaskan portabilitas dan konsistensi generator dibanding enforcement ketat di SQLite.
Hasil Akhir
Dengan pendekatan ini:
- Perpindahan database tidak memerlukan penulisan ulang skema.
- Generator tetap deterministik.
- Kode aplikasi tetap stabil.
- Portabilitas menjadi sekadar perubahan konfigurasi — bukan refactor.
SQLite dalam konteks ini berperan sebagai lapisan kompatibilitas struktur, bukan mesin enforcement utama.
Dan dalam ekosistem multi-dialek, perbedaan ini sangat penting.
Penutup
Portabilitas database bukan dicapai dengan melemahkan struktur.
Portabilitas dicapai dengan menjaga intent struktur lintas dialek.
Dengan menjadikan SQLite sebagai metadata-friendly engine dan mendelegasikan enforcement ketat ke database produksi, MagicAppBuilder menghadirkan fleksibilitas lintas database sejak tahap desain.
Portabilitas bukan fitur tambahan. Ia adalah fondasi arsitektur.