Antipola?
Dalam kasus umum, tabel kedua adalah anti-pola dalam konteks desain database. Dan, terlebih lagi, ia memiliki nama khusus:Entity-Attribute-Value (EAV). Ada beberapa kasus, ketika menggunakan desain ini dibenarkan, tetapi itu adalah kasus yang jarang terjadi - dan bahkan hal itu dapat dihindari.
Mengapa EAV buruk
Dukungan integritas data
Terlepas dari kenyataan bahwa struktur seperti itu tampaknya lebih "fleksibel" atau "maju", desain ini memiliki kelemahan.
- Mustahil membuat atribut wajib . Anda tidak dapat membuat beberapa atribut wajib, karena atribut sekarang disimpan sebagai baris - dan satu-satunya tanda bahwa atribut tidak disetel - adalah bahwa baris yang sesuai tidak ada dalam tabel. SQL tidak akan mengizinkan Anda membuat batasan seperti itu secara asli - jadi, Anda harus memeriksanya di aplikasi - dan, ya, meminta tabel Anda setiap kali
- Pencampuran tipe data . Anda tidak akan dapat menggunakan tipe data standar SQL. Karena kolom nilai Anda harus berupa "tipe super" untuk semua nilai yang tersimpan di dalamnya. Artinya - secara umum Anda harus menyimpan semua data sebagai string mentah . Kemudian Anda akan melihat betapa menyakitkan bekerja dengan tanggal seperti halnya dengan string, setiap kali mentransmisikan tipe data, memeriksa integritas data, dll.
- Tidak mungkin menegakkan integritas referensial . Dalam situasi normal, Anda dapat menggunakan kunci asing untuk membatasi nilai-nilai Anda, yang didefinisikan dalam tabel induk. Tetapi tidak dalam kasus ini - itu karena integritas referensial diterapkan ke setiap baris dalam tabel, tetapi tidak untuk nilai baris. Jadi - Anda akan kehilangan keuntungan ini - dan ini salah satu hal mendasar dalam kaitannya dengan DB
- Tidak mungkin menyetel nama atribut . Itu berarti - Anda tidak dapat membatasi nama atribut pada level DB dengan benar. Misalnya, Anda akan menulis
"customer_name"sebagai nama atribut dalam kasus pertama - dan pengembang lain akan melupakannya dan menggunakan"name_of_customer". Dan.. tidak apa-apa, DB akan melewati itu dan Anda akan berakhir dengan berjam-jam yang dihabiskan untuk men-debug kasus ini.
Rekonstruksi baris
Selain itu, rekonstruksi baris akan sangat buruk dalam kasus umum. Jika Anda memiliki, misalnya, 5 atribut - itu akan menjadi 5 tabel mandiri JOIN -s. Sayang sekali untuk kasus sederhana - sekilas - seperti itu. Jadi saya bahkan tidak ingin membayangkan bagaimana Anda akan mempertahankan 20 atribut.
Bisakah dibenarkan?
Maksud saya adalah - tidak. Di RDBMS akan selalu ada cara untuk menghindari ini. Ini mengerikan. Dan jika EAV dimaksudkan untuk digunakan, maka pilihan terbaik mungkin non-relasional database.
