Cara mereka bentuk jadual produk untuk berbilang produk di mana setiap produk mempunyai banyak parameter

Question

Saya tidak mempunyai banyak pengalaman dalam reka bentuk meja. Matlamat saya adalah untuk mencipta satu atau lebih jadual produk yang memenuhi keperluan berikut:

• Menyokong pelbagai jenis produk (TV, telefon mudah alih, komputer,...). Setiap jenis produk mempunyai set parameter yang berbeza, contohnya:

  • Telefon mudah alih akan mempunyai warna, saiz, berat, sistem pengendalian, dsb.

  • Komputer akan mempunyai CPU, cakera keras, memori, dsb.

• Set parameter mestilah dinamik. Anda boleh menambah atau mengedit sebarang parameter.

Bagaimanakah keperluan ini boleh dipenuhi tanpa membuat jadual berasingan untuk setiap jenis produk?

Answer 1

@StoneHeart

Saya akan sentiasa menggunakan EAV dan MVC.

@Bill Karvin

Semua perkara yang anda nyatakan di sini:

• Pengesahan data
• Pengesahan ejaan nama atribut
• Lajur/medan wajib
• Mengendalikan kemusnahan harta bergantung

Pada pendapat saya, tiada satu pun daripada ini harus berada dalam pangkalan data, kerana tiada pangkalan data boleh mengendalikan interaksi dan keperluan ini pada tahap yang sesuai yang boleh dilakukan oleh bahasa pengaturcaraan aplikasi.

Pada pendapat saya, menggunakan pangkalan data dengan cara ini adalah seperti memukul paku dengan batu. Anda boleh melakukannya dengan batu, tetapi bukankah anda sepatutnya menggunakan tukul yang lebih tepat yang direka khusus untuk aktiviti ini?

Masalah ini boleh diselesaikan dengan melakukan beberapa pertanyaan pada sebahagian data dan memprosesnya menjadi susun atur jadual. Walaupun anda mempunyai 600GB data produk, jika anda perlu mendapatkan data untuk setiap baris daripada jadual ini, anda boleh memprosesnya dalam kelompok.

Selain itu, jika anda ingin meningkatkan prestasi pertanyaan anda, anda boleh memilih operasi tertentu, seperti pelaporan atau carian teks global dan menyediakan jadual indeks untuk menyimpan data yang diperlukan dan menjananya semula secara berkala, katakan setiap 30 minit.

Anda tidak perlu risau tentang kos penyimpanan data tambahan kerana ia semakin murah setiap hari.

Jika anda masih bimbang tentang prestasi operasi yang dilakukan oleh aplikasi, anda sentiasa boleh menggunakan bahasa Erlang, C++, Go untuk mempraproses data dan seterusnya memproses data yang dioptimumkan dalam aplikasi utama.

Answer 2

Anda mempunyai sekurang-kurangnya lima pilihan untuk memodelkan hierarki jenis yang anda huraikan:

• Warisan Meja Tunggal: Gunakan satu jadual untuk semua jenis produk, dengan lajur yang mencukupi untuk menyimpan semua atribut semua jenis. Ini bermakna terdapat banyak lajur pada setiap baris, kebanyakannya adalah NULL pada mana-mana baris tertentu.

• Warisan jadual kelas: Gunakan jadual untuk produk untuk menyimpan atribut biasa semua jenis produk. Kemudian, gunakan jadual untuk setiap jenis produk untuk menyimpan atribut khusus untuk jenis produk tersebut.

• Warisan meja konkrit: Tiada jadual untuk atribut produk biasa. Sebaliknya, gunakan satu jadual untuk setiap jenis produk untuk menyimpan atribut produk biasa dan atribut khusus produk.

• LOB bersiri: Gunakan satu jadual untuk produk untuk menyimpan atribut yang biasa kepada semua jenis produk. Lajur tambahan menyimpan BLOB data separa berstruktur, yang boleh berupa XML, YAML, JSON atau format lain. BLOB ini membolehkan anda menyimpan atribut khusus untuk setiap jenis produk. Anda boleh menggunakan corak reka bentuk yang kompleks untuk menerangkan proses ini, seperti Facade dan Memento. Namun begitu, anda mempunyai BLOB hartanah yang tidak boleh ditanya dengan mudah dalam SQL, anda perlu mengembalikan keseluruhan BLOB ke aplikasi dan menyusunnya di sana.

• Entity-Attribute-Value: Gunakan jadual untuk produk dan jadual yang memutarkan atribut ke dalam baris dan bukannya lajur. EAV bukanlah reka bentuk yang cekap dalam paradigma hubungan, tetapi ramai orang masih menggunakannya. Ini ialah "corak harta" yang disebut dalam jawapan lain. Semak soalan lain yang ditandakan eav pada StackOverflow untuk mengetahui tentang beberapa perangkap.

Saya menulis lebih lanjut tentang perkara ini dalam demo yang dipanggil Pemodelan Data Boleh Skala.

---

Pemikiran lain tentang EAV: Walaupun ramai orang nampaknya menyukai EAV, saya tidak. Ia nampaknya merupakan penyelesaian yang paling fleksibel dan oleh itu yang terbaik. Walau bagaimanapun, sila ingat moto ini TANSTAAFL. Berikut adalah beberapa kelemahan EAV:

• Tidak boleh membuat lajur diperlukan (bersamaan dengan NOT NULL).
• Tidak dapat mengesahkan entri menggunakan jenis data SQL.
• Tidak dapat memastikan ejaan nama hartanah yang konsisten.
• Tidak boleh meletakkan kunci asing pada nilai mana-mana harta yang diberikan, seperti jadual carian.
• Mendapatkan hasil dengan reka letak jadual tradisional adalah rumit dan mahal, kerana mendapatkan atribut untuk berbilang baris memerlukan melakukan JOIN untuk setiap atribut.

Fleksibiliti yang disediakan oleh EAV memerlukan pengorbanan dalam bidang lain, yang berpotensi menjadikan kod anda rumit (atau lebih teruk) berbanding jika anda menyelesaikan masalah asal dengan cara yang lebih tradisional.

Dan, dalam kebanyakan kes, mempunyai tahap fleksibiliti itu adalah tidak perlu. Dalam soalan anda tentang jenis produk, adalah lebih mudah untuk membuat jadual bagi setiap jenis produk untuk menyimpan atribut khusus produk, supaya sekurang-kurangnya beberapa struktur yang konsisten boleh dikuatkuasakan untuk entri jenis produk yang sama.

Saya hanya akan menggunakan EAV jika setiap baris dibenarkan mempunyai set sifat yang berbeza. EAV adalah berlebihan apabila anda mempunyai set jenis produk yang terhad. Warisan jadual kelas akan menjadi pilihan pertama saya.

---

2019 Kemas Kini: Semakin banyak saya melihat orang menggunakan JSON sebagai penyelesaian kepada masalah "banyak sifat tersuai", semakin kurang saya menyukai penyelesaian ini. Walaupun dengan JSON fungsi khas untuk menyokongnya, pertanyaan menjadi terlalu rumit. Menyimpan dokumen JSON memerlukan lebih banyak ruang storan daripada menyimpannya dalam baris dan lajur biasa.

Pada asasnya, dalam pangkalan data hubungan, tiada penyelesaian ini mudah atau cekap. Keseluruhan konsep mempunyai "sifat boleh ubah" pada asasnya tidak konsisten dengan teori hubungan.

Pada penghujung hari, anda perlu memilih salah satu daripada penyelesaian ini berdasarkan cara anda menanyakan data, berdasarkan penyelesaian yang paling tidak buruk untuk aplikasi anda. Oleh itu, sebelum memilih reka bentuk pangkalan data, anda perlu tahu cara membuat pertanyaan data. Tiada penyelesaian yang "terbaik", kerana mana-mana penyelesaian mungkin merupakan pilihan terbaik untuk aplikasi.