Tidak, ini adalah desain yang buruk untuk database relasional. Ini adalah contoh Entity-Attribute-Value desain. Ini fleksibel, tetapi melanggar sebagian besar aturan tentang apa artinya menjadi database relasional.
Sebelum Anda masuk ke desain EAV sebagai solusi untuk database yang fleksibel, baca cerita ini:CaRMa Buruk .
Lebih khusus lagi, beberapa masalah dengan EAV meliputi:
- Anda tidak akan tahu atribut apa yang ada untuk ID_NUM tertentu tanpa menanyakannya.
- Anda tidak dapat mewajibkan atribut apa pun, yang setara dengan NOT NULL.
- Anda tidak dapat menggunakan batasan basis data.
- Anda tidak dapat menggunakan tipe data SQL;
valuekolom harus berupa VARCHAR yang panjang. - Khususnya di MySQL, setiap VARCHAR disimpan di halaman datanya sendiri, jadi ini sangat boros.
Kueri juga sangat kompleks saat Anda menggunakan desain EAV. Magento, platform e-niaga sumber terbuka, menggunakan EAV secara ekstensif, dan banyak pengguna mengatakan bahwa ini sangat lambat dan sulit untuk menanyakan apakah Anda memerlukan laporan khusus.
Agar relasional, Anda harus menyimpan setiap atribut yang berbeda di kolomnya sendiri, dengan namanya sendiri dan tipe data yang sesuai.
Saya telah menulis lebih banyak tentang EAV dalam presentasi saya Berorientasi Objek Praktis Model dalam SQL dan dalam posting blog saya EAV FAIL , dan dalam buku saya, SQL Antipatterns:Menghindari Perangkap Pemrograman Basis Data .
