Katakanlah entitas produk toko, ia memiliki fitur umum, seperti nama, deskripsi, gambar, harga, dll., Yang mengambil bagian dalam logika banyak tempat dan memiliki (semi) fitur unik, seperti arloji dan bola pantai akan dijelaskan oleh aspek yang sama sekali berbeda . Jadi saya pikir EAV cocok untuk menyimpan fitur-fitur unik (semi)?
Menggunakan struktur EAV untuk memiliki beberapa implikasi yang merupakan trade off.
Anda memperdagangkan 'ruang lebih sedikit untuk baris karena Anda tidak memiliki 100 kolom yang null
' menentang 'kueri dan model yang lebih rumit'.
Memiliki EAV biasanya berarti nilainya adalah string tempat seseorang dapat memasukkan data apa pun. Ini kemudian memiliki implikasi pada validitas dan pengecekan kendala. Pertimbangkan situasi di mana Anda telah menempatkan jumlah baterai yang digunakan sebagai sesuatu di tabel EAV. Anda ingin menemukan senter yang menggunakan baterai berukuran C, tetapi kurang dari 4 di antaranya.
select P.sku
from
products P
attrib Ab on (P.sku = Ab.sku and Ab.key = "batteries")
attrib Ac on (P.sku = Ac.sku and Ac.key = "count")
where
cast(Ac.value as int) < 4
and Ab.value = 'C'
...
Hal yang perlu disadari di sini adalah Anda tidak dapat menggunakan indeks secara wajar pada nilainya. Anda juga tidak dapat mencegah seseorang memasukkan sesuatu yang bukan bilangan bulat di sana, atau bilangan bulat tidak valid (menggunakan baterai '-1') karena kolom nilai digunakan berulang kali untuk tujuan yang berbeda.
Ini kemudian memiliki implikasi dalam mencoba menulis model untuk produk tersebut. Anda akan memiliki nilai yang diketik dengan baik ... tetapi Anda juga akan memiliki Map<String,String>
hanya duduk di sana dengan segala macam barang di dalamnya. Hal ini kemudian memiliki implikasi lebih lanjut ketika serialisasi itu ke XML atau JSON dan kompleksitas mencoba untuk melakukan validasi atau query terhadap orang-orang struktur.
Beberapa alternatif atau modifikasi pada pola untuk dipertimbangkan adalah bukan kunci bentuk bebas, untuk memiliki tabel lain dengan kunci yang valid. Itu berarti alih-alih melakukan perbandingan string dalam database, Anda memeriksa terhadap kesetaraan id kunci asing. Mengubah kunci itu sendiri dilakukan di satu tempat. Anda memiliki seperangkat kunci yang dikenal yang berarti bahwa mereka dapat dilakukan sebagai enum.
Anda juga bisa memiliki tabel terkait yang berisi atribut dari kelas produk tertentu. Sebuah departemen kelontong dapat memiliki meja lain yang memiliki beberapa atribut yang terkait dengannya bahwa bahan bangunan tidak perlu (dan sebaliknya).
+----------+ +--------+ +---------+
|Grocery | |Product | |BuildMat |
|id (fk) +--->|id (pk) |<---+id (fk) |
|expiration| |desc | |material |
|... | |img | |... |
+----------+ |price | +---------+
|... |
+--------+
Ada saat-saat yang terutama panggilan untuk meja EAV.
Pertimbangkan situasi di mana Anda tidak hanya menulis sistem inventaris untuk perusahaan Anda di mana Anda mengetahui setiap produk dan setiap atribut. Anda sekarang sedang menulis sistem persediaan untuk dijual ke perusahaan lain. Anda tidak dapat mengetahui setiap atribut dari setiap produk - mereka harus mendefinisikannya.
Satu ide yang keluar adalah "kami akan membiarkan pelanggan memodifikasi tabel" dan ini hanya buruk (Anda masuk ke meta-pemrograman untuk struktur tabel karena Anda tidak lagi tahu di mana, mereka secara meriah dapat merusak struktur atau merusak aplikasi, mereka punya akses untuk melakukan hal-hal yang salah dan implikasi dari akses itu menjadi signifikan). Ada lebih banyak tentang jalur ini di MVC4: Bagaimana cara membuat model saat dijalankan?
Sebagai gantinya, Anda membuat antarmuka administratif ke tabel EAV dan mengizinkannya digunakan. Jika pelanggan ingin membuat entri untuk 'polkadots', ia masuk ke tabel EAV dan Anda sudah tahu cara menghadapinya.
Contohnya dapat dilihat dalam model database untuk Redmine Anda dapat melihat tabel custom_fields, dan tabel custom_values - itu adalah bagian dari EAV yang memungkinkan sistem diperluas.
Perhatikan bahwa jika Anda menemukan seluruh struktur tabel Anda terlihat seperti EAV daripada relasional, Anda mungkin ingin melihat rasa KV dari NoSQL (cassandra, redis, Mongo, ... ...). Sadarilah bahwa ini sering kali disertai pengorbanan lain dalam desain mereka yang mungkin cocok atau tidak sesuai dengan apa yang Anda gunakan. Namun, mereka dirancang khusus dengan maksud struktur EAV.
Anda mungkin ingin membaca SQL vs NoSQL untuk sistem manajemen inventaris
Mengikuti pendekatan ini dengan basis data NoSQL yang berorientasi pada dokumen (sofa, mongo), Anda dapat mempertimbangkan setiap item inventaris sebagai dokumen pada disk ... menarik semuanya dalam satu dokumen dengan cepat. Selanjutnya, dokumen ini disusun sehingga Anda dapat menarik satu hal dengan cepat. Di sisi lain, mencari semua dokumen untuk hal-hal yang cocok dengan atribut tertentu dapat memiliki kinerja yang lebih sedikit (bandingkan dengan menggunakan 'grep' terhadap semua file) ... semuanya merupakan trade off.
Pendekatan lain adalah LDAP di mana seseorang akan memiliki basis dengan semua item yang terkait, tetapi kemudian juga akan memiliki kelas objek tambahan yang diterapkan padanya untuk jenis item lainnya. (lihat Inventarisasi Sistem Menggunakan LDAP )
Setelah Anda menyusuri jalan ini, Anda mungkin menemukan sesuatu yang sama persis dengan apa yang Anda cari ... meskipun semuanya memiliki beberapa pengorbanan.