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 produk (TV, telefon bimbit, PC...). Setiap produk mempunyai set parameter yang berbeza, seperti:
Telefon akan mempunyai warna, saiz, berat, sistem pengendalian...
PC akan ada CPU, HDD, RAM...
Set parameter mestilah dinamik. Anda boleh menambah atau mengedit sebarang parameter yang anda suka.
Bagaimana untuk memenuhi keperluan ini tanpa borang berasingan untuk setiap produk?
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
@StoneHeart
Saya akan sentiasa menggunakan EAV dan MVC untuk ke sini.
@billcavin
Semua perkara yang anda nyatakan di sini:
Pada pendapat saya, ia tidak tergolong dalam pangkalan data sama sekali, kerana tiada pangkalan data boleh mengendalikan interaksi dan keperluan ini pada tahap yang sesuai seperti bahasa pengaturcaraan aplikasi.
Pada pendapat saya, menggunakan pangkalan data dengan cara ini adalah seperti memalu paku dengan batu. Anda boleh melakukan ini dengan batu, tetapi bukankah anda patut menggunakan tukul yang lebih tepat dan direka khusus untuk jenis aktiviti ini?
Masalah ini boleh diselesaikan dengan membuat beberapa pertanyaan pada sebahagian data dan menggunakan aplikasi untuk memprosesnya menjadi susun atur jadual. Walaupun anda mempunyai 600GB data produk, jika anda memerlukan data untuk setiap baris dalam jadual ini, anda boleh memprosesnya secara kelompok.
Selanjutnya, jika anda ingin meningkatkan prestasi pertanyaan anda, anda boleh memilih operasi tertentu seperti pelaporan atau carian teks global dan menyediakan jadual indeks untuknya yang akan menyimpan data yang diperlukan dan dijana semula secara berkala, katakan setiap 30 minit sekali.
Anda tidak perlu risau tentang kos penyimpanan data tambahan kerana ia semakin murah setiap hari.
Jika anda masih mengambil berat tentang prestasi operasi yang dilakukan oleh aplikasi anda, anda sentiasa boleh menggunakan bahasa Erlang, C++, Go untuk pramemproses data dan kemudian memproses data yang dioptimumkan dalam aplikasi utama pada bila-bila masa. p>
Anda mempunyai sekurang-kurangnya lima pilihan berikut untuk memodelkan hierarki jenis yang anda huraikan:
-
Saya menulis lebih lanjut mengenai perkara ini dalam pembentanganWarisan jadual tunggal: Satu jadual digunakan untuk semua jenis produk, dengan lajur yang mencukupi untuk menyimpan semua atribut semua jenis. Ini bermakna banyaklajur, kebanyakannya adalah NULL pada mana-mana baris tertentu.
Warisan jadual kelas: Jadual produk yang menyimpan jenis atribut yang biasa kepada semua produk. Kemudian satu jadual bagi setiap jenis produk, menyimpan atribut khusus untuk jenis produk tersebut.
Warisan meja konkrit: jadual tanpa atribut produk biasa. Sebaliknya, satu jadual bagi setiap jenis produk menyimpan atribut produk biasa dan atribut khusus produk.
LOB bersiri: Jadual produk yang menyimpan atribut biasa kepada semua jenis produk. Lajur tambahan menyimpan BLOB data separa berstruktur dalam XML, YAML, JSON atau beberapa format lain. BLOB ini membolehkan anda menyimpan atribut khusus untuk setiap jenis produk. Anda boleh menggunakan corak reka bentuk yang mewah untuk menerangkan perkara ini, seperti Fasad dan Memento. Tetapi tidak kira apa, anda tidak boleh dengan mudah menanyakan sejumlah besar sifat dalam SQL anda perlu mengekstrak keseluruhan gumpalan kembali ke aplikasi dan mengisihnya di sana.
Entity-Attribute-Value: Jadual produk dan jadual yang memutarkan atribut ke dalam baris dan bukannya lajur. EAV bukanlah reka bentuk yang sah setakat paradigma hubungan, tetapi ramai orang masih menggunakannya. Ini ialah "corak harta" yang disebutkan dalam jawapan lain. Lihat soalan lain yang ditandakan eav pada StackOverflow untuk beberapa masalah.
Pemodelan Data Berskala.
Pemikiran lain tentang EAV: Walaupun ramai orang nampaknya menyukai EAV, saya tidak. Ini nampaknya merupakan penyelesaian yang paling fleksibel dan oleh itu yang terbaik. Tetapi, ingat moto ini
TANSTAAFL. Berikut adalah beberapa keburukan EAV:
NOT NULL).JOINuntuk setiap atribut.Tahap fleksibiliti EAV memerlukan anda melakukan pengorbanan dalam bidang lain, yang mungkin menjadikan kod anda lebih kompleks (atau lebih teruk) daripada menyelesaikan masalah asal dengan cara yang lebih tradisional.
Dan dalam kebanyakan kes, tahap fleksibiliti ini tidak perlu. Dalam soalan OP tentang jenis produk, adalah lebih mudah untuk membuat jadual untuk atribut khusus produk untuk setiap jenis produk, dengan itu sekurang-kurangnya menguatkuasakan beberapa struktur yang konsisten untuk entri jenis produk yang sama.
Saya hanya akan menggunakan EAV jika perlu untuk membenarkan setiap baris berpotensi mempunyai set sifat yang berbeza. EAV adalah berlebihan apabila anda mempunyai rangkaian produk yang terhad. Warisan jadual kelas akan menjadi pilihan pertama saya.
Kemas kini 2019: Semakin saya melihat orang menggunakan JSON sebagai penyelesaian kepada masalah "banyak sifat tersuai", semakin saya kurang menyukai penyelesaian itu. Walaupun menggunakan JSON fungsi khas，它也会使查询变得过于复杂> menyokongnya. Menyimpan dokumen JSON memerlukan lebih banyak ruang storan daripada menyimpannya dalam baris dan lajur biasa.
Pada asasnya, tiada penyelesaian ini mudah atau cekap dalam pangkalan data hubungan. Keseluruhan idea untuk mempunyai "sifat boleh ubah" pada asasnya tidak konsisten dengan teori hubungan.
Pada penghujung hari, anda perlu memilih penyelesaian yang mempunyai kesan paling sedikit pada apl anda. Oleh itu, sebelum memilih reka bentuk pangkalan data, anda perlu tahu cara membuat pertanyaan data. Tiada cara untuk memilih satu penyelesaian "terbaik", kerana sebarang penyelesaian mungkin terbaik untuk aplikasi tertentu.