Sebenarnya desain yang Anda jelaskan (tabel umum ditambah tabel khusus subtipe) disebut Pewarisan Tabel Kelas .
Warisan Tabel Beton akan memiliki semua atribut umum yang diduplikasi dalam tabel subtipe, dan Anda tidak akan memiliki tabel supertipe seperti sekarang.
Saya sangat menentang EAV. Saya menganggapnya sebagai antipattern SQL. Ini mungkin tampak seperti solusi yang elegan karena membutuhkan lebih sedikit tabel, tetapi Anda akan membuat diri Anda pusing nantinya. Anda mengidentifikasi beberapa kelemahannya, tetapi ada banyak kekurangan lainnya. IMHO, EAV digunakan dengan tepat hanya jika Anda benar-benar tidak boleh buat tabel baru saat Anda memperkenalkan subtipe baru, atau jika Anda memiliki jumlah subtipe yang tidak terbatas (mis. pengguna dapat menentukan atribut baru secara ad hoc).
Anda memiliki banyak subtipe, tetapi jumlahnya masih terbatas, jadi jika saya melakukan proyek ini, saya akan tetap menggunakan Class Table Inheritance . Anda mungkin memiliki beberapa baris dari setiap subtipe, tetapi setidaknya Anda memiliki jaminan bahwa semua baris di setiap subtipe memiliki kolom yang sama, Anda dapat menggunakan NOT NULL jika perlu, Anda dapat menggunakan tipe data SQL, Anda dapat menggunakan batasan integritas referensial, dll. Dari perspektif relasional, ini adalah desain yang lebih baik daripada EAV.
Satu opsi lagi yang tidak Anda sebutkan disebut LOB Berseri . Artinya, tambahkan kolom BLOB untuk kumpulan atribut kustom semi-terstruktur. Simpan XML, YAML, JSON, atau DSL Anda sendiri di kolom itu. Anda tidak akan dapat mengurai atribut individual dari BLOB itu dengan mudah dengan SQL, Anda harus mengambil seluruh BLOB kembali ke aplikasi Anda dan mengekstrak atribut individual dalam kode. Jadi dalam beberapa hal itu kurang nyaman. Tetapi jika itu memuaskan penggunaan data Anda, maka tidak ada yang salah dengan itu.
