Monitor, laptop, dan power supply hampir tidak punya kesamaan di lembar spesifikasi. Monitor punya tipe panel, refresh rate, dan response time. Laptop punya CPU, RAM, dan kapasitas baterai. Power supply punya wattage, rating efisiensi, dan modularitas.
Sistem yang digantikan ini adalah spreadsheet per kategori, yang berarti membandingkan dua kategori dilakukan manual dan pelaporannya salin-tempel. Skema relasional dengan satu kolom per atribut akan butuh migrasi untuk setiap tipe produk baru.
Kolom yang lentur, bingkai yang tetap
Komprominya adalah JSONB untuk atributnya, di dalam tabel yang menjaga bagian relasional tetap relasional. Baris produk menyimpan identitas, kategori, dan relasinya di kolom biasa. Blok spesifikasinya adalah kolom JSONB yang bentuknya bergantung pada kategori.
model Product {
id String @id @default(cuid())
categoryId String
category Category @relation(fields: [categoryId], references: [id])
attributes Json
createdAt DateTime @default(now())
}Yang didapat adalah menambah kategori produk baru menjadi pekerjaan data, bukan deployment. Yang dibayar adalah database tidak bisa menegakkan bentuknya, jadi aplikasi yang harus.
Definisi yang memiliki form-nya
Setiap kategori membawa skema: daftar field berurutan dengan tipe, satuan, dan apakah bisa dibandingkan. Form admin dihasilkan dari skema itu, dan tampilan perbandingan membaca skema yang sama untuk memutuskan kolom mana yang sejajar.
Satu definisi yang memberi makan keduanya inilah yang membuat kelenturan itu terpakai. Saat form dan tabel perbandingan dibangun dari sumber berbeda, keduanya melenceng, dan field yang ada di satu menghilang dari yang lain. Di sini itu tidak mungkin, karena hanya ada satu tempat untuk mengubah.
Validasi mengikuti aturan yang sama. Skema menyatakan sebuah field numerik dengan satuan, jadi API menolak string sebelum mencapai kolom. JSONB menghapus pemeriksaan tipe dari database, yang berarti lapisan aplikasi harus mengambilnya dengan serius alih-alih memperlakukan kolom itu sebagai kantong bebas.
Perbandingan butuh baseline
Tampilan perbandingan membandingkan produk dalam satu kategori terhadap baseline yang dipilih, menandai lebih baik dan lebih buruk per field. Itu membutuhkan pengetahuan arah mana yang lebih baik, yang merupakan sifat field, bukan nilai: refresh rate lebih tinggi lebih baik, response time lebih tinggi tidak.
Menyimpan arah itu di definisi field, bersebelahan dengan satuan, menjaga logika perbandingan tetap generik. Alternatifnya adalah daftar hardcoded atribut mana yang terbalik, dan itu justru daftar yang basi begitu seseorang menambah kategori.
