Data: Database dan SQL · 7/7

ORM, query builder, dan migration

Apa yang kamu dapat dari ORM dan apa yang disembunyikannya, plus cara mengubah skema dengan aman di sistem live.

Baca 30 menit

Setelah pelajaran ini kamu bisa

Menyebutkan apa yang diberikan ORM dan apa yang disembunyikannya
Mengenali masalah query N+1
Menjelaskan kenapa perubahan skema harus berupa migration
Mengubah skema yang sudah live tanpa merusak aplikasi yang berjalan

ORM — object-relational mapper — memungkinkanmu menulis db.venue.findMany() alih-alih SQL. Query builder berada di antaranya, lebih dekat ke SQL tapi bisa dikomposisi di JavaScript.

Pendekatan	Contoh	Pertukarannya
SQL mentah	`node:sqlite`, `pg`	Kontrol penuh, tanggung jawab penuh
Query builder	Kysely, Knex	Bertype dan bisa dikomposisi, tetap jelas terlihat SQL
ORM	Prisma, Drizzle, TypeORM	Paling cepat ditulis, paling mudah jadi lambat tanpa sengaja

Masalah N+1

Ini bug performa paling umum yang dibuat mudah oleh ORM, dan ia tak terlihat di kodenya. Kamu mengambil sebuah list, lalu mengulanginya sambil mengambil sesuatu untuk setiap item — satu query untuk list-nya, plus N untuk item-nya.

Coba sendiri

Halaman yang sama, dua strategi query. Hitung perjalanan bolak-baliknya.

const venues = [
  { id: 1, name: "Villa Sunset", ownerId: 1 },
  { id: 2, name: "Villa Rain", ownerId: 1 },
  { id: 3, name: "Kos Melati", ownerId: 2 },
];
const owners = [{ id: 1, name: "Ana" }, { id: 2, name: "Budi" }];

let queries = 0;
const ROUND_TRIP_MS = 2;                    // a realistic per-query cost

// --- N+1: one query for the list, one per row ---
queries = 0;
const naive = findVenues().map((v) => ({ venue: v.name, owner: findOwner(v.ownerId).name }));
const naiveQueries = queries;

// --- batched: one query for the list, one for all the owners ---
queries = 0;
const list = findVenues();
const ownerRows = findOwnersIn([...new Set(list.map((v) => v.ownerId))]);
const byId = new Map(ownerRows.map((o) => [o.id, o]));
const batched = list.map((v) => ({ venue: v.name, owner: byId.get(v.ownerId).name }));
const batchedQueries = queries;

console.log("results identical:", JSON.stringify(naive) === JSON.stringify(batched));
console.log("");
console.log("N+1:     " + naiveQueries + " queries  = " + naiveQueries * ROUND_TRIP_MS + "ms of round trips");
console.log("batched: " + batchedQueries + " queries  = " + batchedQueries * ROUND_TRIP_MS + "ms");
console.log("");
console.log("With 3 venues that is 4 queries versus 2. Nobody notices.");
console.log("With 500 venues it is 501 versus 2:");
console.log("   N+1:     " + (501 * ROUND_TRIP_MS) + "ms");
console.log("   batched: " + (2 * ROUND_TRIP_MS) + "ms");
console.log("");
console.log("The code looked the same. Only the data grew.");

Hasil

Tekan Jalankan untuk melihat hasilnya.

Ini jalan di browser kamu, di dalam sandbox. Apa pun yang kamu tulis di sini tidak bisa merusak situs.

Migration

Migration adalah perubahan skema yang berversi dan berurutan, di-commit ke git. Kamu tidak pernah mengedit database yang live secara manual, karena database rekan-rekanmu dan production akan jadi berbeda dari milikmu tanpa catatan bagaimana.

Coba sendiri

Sebuah migration runner, dan memang cuma inilah isinya: sebuah nomor versi dan daftar berurutan.

// Each entry is one version. Append only - NEVER edit a shipped one.
const MIGRATIONS = [
  ["CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL)"],
  ["CREATE TABLE venues (id INTEGER PRIMARY KEY, name TEXT NOT NULL)"],
  ["ALTER TABLE venues ADD COLUMN price INTEGER", "CREATE INDEX venues_name ON venues(name)"],
];

function createDatabase() {
  return { version: 0, applied: [], failNext: false };
}

const fresh = createDatabase();
console.log("fresh database:      " + migrate(fresh));
console.log("   statements applied: " + fresh.applied.length);

console.log("");
console.log("running again (should be a no-op):");
console.log("   " + migrate(fresh) + ", statements applied: " + fresh.applied.length);

console.log("");
console.log("a database that fails partway through version 3:");
const broken = createDatabase();
broken.failNext = true;
console.log("   " + migrate(broken));
console.log("   version stayed at " + broken.version + ", applied " + broken.applied.length + " statements");
console.log("   Without the rollback, version 3 would be half-applied and");
console.log("   re-running would try to create the table again.");

Hasil

Tekan Jalankan untuk melihat hasilnya.

Ini jalan di browser kamu, di dalam sandbox. Apa pun yang kamu tulis di sini tidak bisa merusak situs.

Itu tepatnya bentuk migrate() di proyek ini, yang melacak versinya di pragma user_version milik SQLite sendiri sehingga tidak butuh tabel tambahan. Bacalah — panjangnya sekitar dua puluh baris.

Mengubah skema live dengan aman

Bagian sulitnya bukan SQL-nya — tapi kenyataan bahwa kode lama dan kode baru berjalan bersamaan selama proses deploy. Penggantian nama yang dilakukan dalam satu langkah akan merusak versi mana pun yang tidak mengharapkannya.

Tambahkan kolom barunya, boleh null. Kode lama mengabaikannya; kode baru bisa mulai menulisinya.
Deploy kode yang menulis ke kolom lama dan kolom baru.
Isi ulang (backfill) kolom baru untuk row yang sudah ada.
Deploy kode yang membaca kolom barunya.
Berhenti menulis kolom lama, lalu buang di migration berikutnya.

Tugas praktik

Tambahkan sebuah migration ke proyek ini: entri keempat di MIGRATIONS yang menambahkan kolom display_name yang nullable ke users, plus sebuah index padanya. Restart dev, lalu pastikan dengan PRAGMA user_version bahwa versinya maju ke 2. Lalu coba tambahkan kolom NOT NULL tanpa default dan lihat ia gagal — lalu perbaiki dengan cara yang aman.

Hasil yang diharapkan

user_version jadi 2; percobaan NOT NULL gagal pada row yang sudah ada.