Database Nilai Atribut Entitas vs. E-niaga Model Relasional yang ketat

Dapat dikatakan bahwa model database EAV / CR buruk. Yang mengatakan,

Pertanyaan: Model database, teknik, atau pola apa yang harus digunakan untuk menangani "kelas" atribut yang mendeskripsikan produk e-commerce yang dapat diubah pada waktu proses?

Dalam database E-commerce yang baik, Anda akan menyimpan beberapa kelas opsi (seperti resolusi TV, kemudian memiliki resolusi untuk setiap TV, tetapi produk berikutnya mungkin bukan TV dan tidak memiliki "resolusi TV"). Bagaimana Anda menyimpannya, mencari secara efisien, dan memungkinkan pengguna Anda untuk mengatur jenis produk dengan kolom variabel yang menjelaskan produk mereka? Jika mesin telusur menemukan bahwa pelanggan biasanya menelusuri TV berdasarkan kedalaman konsol, Anda dapat menambahkan kedalaman konsol ke bidang Anda, lalu menambahkan kedalaman tunggal untuk setiap jenis produk TV pada waktu proses.

Ada fitur umum yang bagus di antara aplikasi e-niaga yang bagus di mana mereka menampilkan sekumpulan produk, lalu memiliki menu samping "lihat perincian" di mana Anda dapat melihat "Resolusi TV" sebagai tajuk, dan lima Resolusi TV paling umum untuk set ditemukan. Anda mengklik satu dan itu hanya menampilkan TV dengan resolusi itu, memungkinkan Anda untuk menelusuri lebih lanjut dengan memilih kategori lain di menu samping. Opsi ini akan menjadi atribut produk dinamis yang ditambahkan pada waktu proses.

Diskusi lebih lanjut:

Singkat cerita, apakah ada tautan di Internet atau deskripsi model yang dapat "secara akademis" memperbaiki penyiapan berikut? Saya berterima kasih kepada Noel Kennedy karena menyarankan tabel kategori, tetapi kebutuhannya mungkin lebih besar dari itu. Saya menjelaskannya dengan cara berbeda di bawah ini, mencoba untuk menyoroti signifikansinya. Saya mungkin memerlukan koreksi sudut pandang untuk memecahkan masalah, atau saya mungkin perlu mempelajari lebih dalam tentang EAV / CR.

Suka respons positif terhadap model EAV / CR. Semua rekan pengembang saya mengatakan apa yang disinggung Jeffrey Kemp di bawah ini: "entitas baru harus dimodelkan dan dirancang oleh seorang profesional" (diambil di luar konteks, baca tanggapannya di bawah). Masalahnya adalah:

• entitas menambah dan menghapus atribut setiap minggu
  (kata kunci pencarian mendikte atribut masa depan)
• entitas baru tiba setiap minggu
  (produk dirakit dari bagian-bagian)
• entitas lama menghilang setiap minggu
  (diarsipkan, kurang populer, musiman)

Pelanggan ingin menambahkan atribut ke produk karena dua alasan:

• departemen / pencarian kata kunci / grafik perbandingan antara produk sejenis
• konfigurasi produk konsumen sebelum pembayaran

Atribut harus memiliki makna, bukan hanya pencarian kata kunci. Jika mereka ingin membandingkan semua kue yang memiliki "frosting krim kocok", mereka dapat mengeklik kue, klik tema ulang tahun, klik hiasan krim kocok, lalu centang semua kue yang menarik karena mengetahui bahwa semua kue memiliki frosting krim kocok. Ini tidak khusus untuk kue, hanya sebuah contoh.

Ada beberapa pro dan kontra umum yang dapat saya pikirkan, ada situasi di mana yang satu lebih baik dari yang lain:

Opsi 1, Model EAV:

• Pro: lebih sedikit waktu untuk merancang dan mengembangkan aplikasi sederhana
• Pro: entitas baru mudah ditambahkan (bahkan mungkin ditambahkan oleh pengguna?)
• Pro: komponen antarmuka "generik"
• Kontra: kode kompleks diperlukan untuk memvalidasi tipe data sederhana
• Kontra: SQL yang jauh lebih kompleks untuk laporan sederhana
• Kontra: laporan yang kompleks bisa menjadi hampir tidak mungkin
• Kontra: kinerja yang buruk untuk kumpulan data besar

Opsi 2, Memodelkan setiap entitas secara terpisah:

• Kontra: lebih banyak waktu yang dibutuhkan untuk mengumpulkan persyaratan dan desain
• Kontra: entitas baru harus dimodelkan dan dirancang oleh seorang profesional
• Con: komponen antarmuka kustom untuk setiap entitas
• Pro: batasan tipe data dan validasi mudah diterapkan
• Pro: SQL mudah ditulis, mudah dipahami, dan debug
• Pro: bahkan laporan yang paling rumit pun relatif sederhana
• Pro: kinerja terbaik untuk kumpulan data besar

Opsi 3, Kombinasi (model entitas "dengan benar", tetapi tambahkan "ekstensi" untuk atribut khusus untuk beberapa / semua entitas)

• Pro / Kontra: lebih banyak waktu yang dibutuhkan untuk mengumpulkan persyaratan dan desain daripada opsi 1 tetapi mungkin tidak sebanyak opsi 2 *
• Kontra: entitas baru harus dimodelkan dan dirancang oleh seorang profesional
• Pro: atribut baru mungkin dengan mudah ditambahkan nanti
• Kontra: kode kompleks diperlukan untuk memvalidasi tipe data sederhana (untuk atribut khusus)
• Kontra: komponen antarmuka khusus masih diperlukan, tetapi komponen antarmuka umum dapat digunakan untuk atribut khusus
• Kontra: SQL menjadi kompleks segera setelah atribut khusus apa pun disertakan dalam laporan
• Kontra: kinerja yang baik secara umum, kecuali Anda mulai perlu mencari atau melaporkan berdasarkan atribut khusus

* Saya tidak yakin apakah Opsi 3 akan menghemat waktu dalam fase desain.

Secara pribadi saya akan condong ke opsi 2, dan menghindari EAV sedapat mungkin. Namun, untuk beberapa skenario, pengguna memerlukan fleksibilitas yang disertakan dengan EAV; tapi ini harus dibayar mahal.

Dapat dikatakan bahwa model database EAV / CR buruk.

Tidak. Hanya saja mereka adalah penggunaan database relasional yang tidak efisien. Penyimpanan kunci / nilai murni berfungsi baik dengan model ini.

Sekarang, ke pertanyaan Anda yang sebenarnya: Bagaimana cara menyimpan berbagai atribut dan membuatnya tetap dapat dicari?

Cukup gunakan EAV. Dalam kasus Anda, ini akan menjadi satu tabel ekstra. mengindeksnya pada nama dan nilai atribut, kebanyakan RDBM akan menggunakan kompresi prefiks untuk pengulangan nama atribut, membuatnya sangat cepat dan ringkas.

EAV / CR menjadi jelek saat Anda menggunakannya untuk menggantikan bidang 'nyata'. Seperti setiap alat, menggunakannya secara berlebihan adalah 'buruk', dan memberikan citra yang buruk.

// Pada titik ini, saya ingin meluangkan waktu sejenak untuk berbicara dengan Anda tentang format Magento / Adobe PSD .
// Magento / PSD bukanlah platform / format e-niaga yang baik . Magento / PSD bahkan bukan platform / format e-niaga yang buruk . Menyebutnya seperti itu akan menjadi
// menghina platform / format e-niaga buruk lainnya , seperti Zencart atau OsCommerce. Tidak, Magento / PSD adalah platform / format e-niaga yang buruk . Memiliki
// Bekerja pada kode ini selama beberapa minggu sekarang, kebencian saya pada Magento / PSD telah berkembang menjadi api yang berkobar
// Itu membara dengan gairah sengit sejuta matahari.

http://code.google.com/p/xee/source/browse/trunk/XeePhotoshopLoader.m?spec=svn28&r=11#107

Model internal paling aneh, seperti seseorang memasukkan skema ke dalam permainan boggle, menyegelnya dan memasukkannya ke dalam pengocok cat ...

Dunia nyata: Saya sedang mengerjakan aplikasi pemenuhan midware dan berikut adalah salah satu pertanyaan untuk mendapatkan informasi alamat.

CREATE OR REPLACE VIEW sales_flat_addresses AS
SELECT sales_order_entity.parent_id AS order_id, 
       sales_order_entity.entity_id, 
       CONCAT(CONCAT(UCASE(MID(sales_order_entity_varchar.value,1,1)),MID(sales_order_entity_varchar.value,2)), "Address") as type, 
       GROUP_CONCAT( 
         CONCAT( eav_attribute.attribute_code," ::::: ", sales_order_entity_varchar.value )
         ORDER BY sales_order_entity_varchar.value DESC
         SEPARATOR '!!!!!' 
       ) as data
  FROM sales_order_entity
       INNER JOIN sales_order_entity_varchar ON sales_order_entity_varchar.entity_id = sales_order_entity.entity_id
       INNER JOIN eav_attribute ON eav_attribute.attribute_id = sales_order_entity_varchar.attribute_id
   AND sales_order_entity.entity_type_id =12
 GROUP BY sales_order_entity.entity_id
 ORDER BY eav_attribute.attribute_code = 'address_type'

Informasi alamat yang tepat untuk pesanan, malas

-

Ringkasan: Gunakan Magento hanya jika:

1. Anda diberi banyak uang
2. Kamu harus
3. Nikmati rasa sakit

Saya terkejut tidak ada yang menyebutkan database NoSQL.

Saya tidak pernah mempraktikkan NoSQL dalam konteks produksi (baru saja menguji MongoDB dan terkesan) tetapi inti dari NoSQL adalah dapat menyimpan item dengan atribut yang berbeda-beda dalam "dokumen" yang sama.

Di mana kinerja bukan merupakan persyaratan utama, seperti dalam jenis aplikasi ETL, EAV memiliki keunggulan lain: penghematan diferensial.

Saya telah menerapkan sejumlah aplikasi di mana persyaratan yang berlebihan adalah kemampuan untuk melihat riwayat objek domain dari "versi" pertama hingga statusnya saat ini. Jika objek domain tersebut memiliki sejumlah besar atribut, itu berarti setiap perubahan memerlukan baris baru untuk dimasukkan ke dalam tabel yang sesuai (bukan pembaruan karena riwayat akan hilang, tetapi sisipan). Katakanlah objek domain ini adalah Orang, dan saya memiliki 500 ribu Orang untuk dilacak dengan rata-rata 100+ perubahan selama siklus hidup Orang ke berbagai atribut. Pasangkan dengan fakta bahwa rare adalah aplikasi yang hanya memiliki 1 objek domain utama dan Anda akan segera menduga bahwa ukuran database akan cepat tumbuh di luar kendali.

Solusi yang mudah adalah dengan hanya menyimpan perubahan diferensial ke objek domain utama daripada berulang kali menyimpan informasi yang berlebihan.

Semua model berubah seiring waktu untuk mencerminkan kebutuhan bisnis baru. Titik. Menggunakan EAV hanyalah salah satu alat di kotak kami untuk digunakan; tetapi tidak boleh secara otomatis diklasifikasikan sebagai "buruk".

Saya berjuang dengan masalah yang sama. Mungkin menarik bagi Anda untuk melihat pembahasan berikut tentang dua solusi e-niaga yang ada: Magento (EAV) dan Joomla (struktur relasional reguler): https://forum.virtuemart.net/index.php?topic=58686.0

Tampaknya, kinerja EAV Magento adalah penghenti yang nyata.

Itulah mengapa saya condong ke struktur yang dinormalisasi. Untuk mengatasi kurangnya fleksibilitas, saya berpikir tentang menambahkan beberapa kamus data terpisah di masa mendatang (XML atau tabel DB terpisah) yang dapat diedit, dan berdasarkan itu, kode aplikasi untuk menampilkan dan membandingkan kategori produk dengan kumpulan atribut baru akan menjadi dihasilkan, bersama dengan skrip SQL.

Arsitektur seperti itu tampaknya menjadi yang terbaik dalam hal ini - fleksibel dan berkinerja pada saat yang sama.

Masalahnya bisa jadi sering menggunakan ALTER TABLE di lingkungan hidup. Saya menggunakan Postgres, jadi MVCC dan DDL transaksionalnya mudah-mudahan akan mengurangi rasa sakit.

Saya masih memilih pemodelan di tingkat atom yang paling rendah untuk EAV. Biarkan standar, teknologi, dan aplikasi yang mengarah pada komunitas pengguna tertentu untuk memutuskan model konten, kebutuhan pengulangan atribut, biji-bijian, dll.

Jika ini hanya tentang atribut katalog produk dan karenanya persyaratan validasi untuk atribut tersebut agak terbatas, satu-satunya kelemahan EAV adalah kinerja kueri dan bahkan itu hanya menjadi masalah ketika kueri Anda berurusan dengan beberapa "hal" (produk) dengan atribut, kinerja untuk kueri "beri saya semua atribut untuk produk dengan id 234" sementara tidak optimal masih cukup cepat.

Salah satu solusinya adalah dengan menggunakan database SQL / model EAV hanya untuk sisi admin / edit katalog produk dan memiliki beberapa proses yang mendenormalisasi produk menjadi sesuatu yang membuatnya dapat dicari. Karena Anda sudah memiliki atribut dan karena itu kemungkinan besar Anda ingin faceting, ini bisa berupa Solr atau ElasticSearch. Pendekatan ini pada dasarnya menghindari semua kerugian pada model EAV dan kompleksitas tambahan terbatas pada serialisasi produk lengkap ke JSON saat pembaruan.

EAV memiliki banyak kekurangan:

1. Penurunan kinerja dari waktu ke waktu Setelah jumlah data dalam aplikasi bertambah melebihi ukuran tertentu, pengambilan dan manipulasi data tersebut cenderung menjadi semakin tidak efisien.
2. Kueri SQL sangat kompleks dan sulit untuk ditulis.
3. Masalah Integritas Data. Anda tidak dapat menentukan kunci asing untuk semua bidang yang diperlukan.
4. Anda harus mendefinisikan dan memelihara metadata Anda sendiri.

Saya memiliki masalah yang sedikit berbeda: alih-alih banyak atribut dengan nilai renggang (yang mungkin merupakan alasan bagus untuk menggunakan EAV), saya ingin menyimpan sesuatu yang lebih seperti spreadsheet. Kolom di sheet bisa berubah, tapi di dalam sheet semua sel akan berisi data (tidak sparse).

Saya membuat serangkaian tes kecil untuk membandingkan dua desain: satu menggunakan EAV, dan yang lainnya menggunakan Postgres ARRAY untuk menyimpan data sel.

EAV

Himpunan

Kedua skema memiliki indeks pada kolom yang sesuai, dan indeks digunakan oleh perencana.

Ternyata skema berbasis larik adalah urutan besarnya lebih cepat untuk penyisipan dan kueri. Dari tes cepat, tampaknya keduanya diskalakan secara linier. Tesnya tidak terlalu teliti. Saran dan garpu diterima - semuanya di bawah lisensi MIT.