Menyematkan struktur data di bidang dapat berfungsi untuk kasus sederhana tetapi mencegah Anda mengambil keuntungan dari database relasional. Database relasional dirancang untuk menemukan, memperbarui, menghapus, dan melindungi data Anda. Dengan bidang tersemat yang berisi data wad-o-nya sendiri (array, JSON, xml, dll.), Anda akhirnya menulis semua kode untuk melakukannya sendiri.
Ada kasus di mana bidang yang disematkan mungkin lebih cocok, tetapi untuk pertanyaan ini sebagai contoh, saya akan menggunakan kasus yang menyoroti keuntungan dari pendekatan tabel terkait.
Bayangkan contoh Pengguna dan Postingan untuk sebuah blog.
Untuk solusi posting yang disematkan, Anda akan memiliki tabel seperti ini (psuedocode - ini mungkin bukan ddl yang valid):
create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}
Dengan tabel terkait, Anda akan melakukan sesuatu seperti
create table Users {
id int auto_increment,
name varchar(200)
}
create table Posts {
id auto_increment,
user_id int,
content text
}
Alat Pemetaan Relasional Objek (ORM) :Dengan posting yang disematkan, Anda akan menulis kode secara manual untuk menambahkan posting ke pengguna, menavigasi melalui posting yang ada, memvalidasinya, menghapusnya, dll. Dengan desain tabel terpisah, Anda dapat memanfaatkan ActiveRecord (atau sistem relasional objek apa pun yang Anda menggunakan) alat untuk ini yang seharusnya membuat kode Anda lebih sederhana.
Fleksibilitas :Bayangkan Anda ingin menambahkan bidang tanggal ke pos. Anda dapat melakukannya dengan bidang tertanam, tetapi Anda harus menulis kode untuk mengurai array Anda, memvalidasi bidang, memperbarui posting tertanam yang ada, dll. Dengan tabel terpisah, ini jauh lebih sederhana. Selain itu, katakanlah Anda ingin menambahkan Editor ke sistem Anda yang menyetujui semua posting. Dengan contoh relasional ini mudah. Sebagai contoh untuk menemukan semua posting yang diedit oleh 'Bob' dengan ActiveRecord, Anda hanya perlu:
Editor.where(name: 'Bob').posts
Untuk sisi yang disematkan, Anda harus menulis kode untuk menelusuri setiap pengguna dalam database, mengurai setiap posting mereka dan mencari 'Bob' di bidang editor.
Kinerja :Bayangkan Anda memiliki 10.000 pengguna dengan rata-rata 100 posting masing-masing. Sekarang Anda ingin menemukan semua posting yang dilakukan pada tanggal tertentu. Dengan bidang yang disematkan, Anda harus mengulang setiap catatan, mengurai seluruh larik semua posting, mengekstrak tanggal dan memeriksa tanggal yang Anda inginkan. Ini akan mengunyah cpu dan disk i/0. Untuk database, Anda dapat dengan mudah mengindeks bidang tanggal dan mengeluarkan catatan persis yang Anda butuhkan tanpa menguraikan setiap posting dari setiap pengguna.
Standar :Menggunakan struktur data khusus vendor berarti memindahkan aplikasi Anda ke database lain bisa jadi merepotkan. Postgres tampaknya memiliki kumpulan tipe data yang kaya, tetapi mereka tidak sama dengan MySQL, Oracle, SQL Server, dll. Jika Anda tetap menggunakan tipe data standar, Anda akan lebih mudah menukar backend.
Ini adalah masalah utama yang saya lihat dari atas. Saya telah membuat kesalahan ini dan membayar harganya, jadi kecuali ada alasan yang sangat kuat, lakukan sebaliknya, saya akan menggunakan tabel terpisah.
