Adakah menyimpan senarai terhad dalam lajur pangkalan data benar-benar buruk?

Question

Bayangkan borang web dengan satu set kotak pilihan (mana-mana atau kesemuanya boleh dipilih). Saya memilih untuk menyimpannya dalam senarai nilai yang dipisahkan koma yang disimpan dalam lajur dalam jadual pangkalan data. Sekarang, saya tahu penyelesaian yang betul ialah mencipta jadual kedua dan menormalkan pangkalan data dengan betul. Lebih cepat untuk melaksanakan penyelesaian mudah dan saya ingin mendapatkan bukti konsep aplikasi dengan cepat tanpa perlu menghabiskan terlalu banyak masa untuknya. Saya rasa penjimatan masa dan kod yang lebih mudah adalah berbaloi dalam kes saya, adakah ini pilihan reka bentuk yang munasabah atau patutkah saya menyeragamkan ini dari awal? Untuk lebih banyak konteks, ini adalah

P粉948258958 · Answer

"Salah satu sebabnya ialah malas".

Ini adalah panggilan bangun. Satu-satunya sebab anda perlu melakukan sesuatu seperti ini adalah kerana anda tahu cara melakukannya "dengan cara yang betul", tetapi anda membuat kesimpulan bahawa ada sebab kukuh untuk tidak melakukannya.

Seperti yang dinyatakan: Jika data yang anda pilih untuk menyimpan dengan cara ini ialah data yang anda tidak perlu bertanya, maka mungkin terdapat kes untuk menyimpannya mengikut cara yang anda pilih.

(Sesetengah pengguna akan mengambil isu dengan kenyataan saya dalam perenggan sebelumnya, dengan mengatakan "anda tidak pernah tahu keperluan apa yang boleh ditambah pada masa hadapan". Pengguna ini sama ada salah maklumat atau menyatakan kepercayaan agama. Kadangkala, adalah berfaedah untuk bekerja keras untuk keperluan di hadapan anda )

P粉545956597 · Answer

Selain melanggar Borang Biasa Pertama, terdapat banyak masalah lain yang lebih praktikal dengan lajur nilai kumpulan berulang yang disimpan dalam senarai tunggal yang dipisahkan koma:

Tiada cara untuk memastikan setiap nilai adalah jenis data yang betul: Tidak dapat menghalang 1,2,3,pisang,5
Anda tidak boleh menggunakan kekangan kunci asing untuk memautkan nilai ke jadual carian; anda tidak boleh menguatkuasakan integriti rujukan.
Tidak dapat memaksa keunikan: Tidak dapat menyekat 1,2,3,3,3,5
Anda tidak boleh mengalih keluar nilai daripada senarai tanpa mendapat keseluruhan senarai.
Panjang senarai yang disimpan tidak boleh melebihi panjang lajur rentetan.
Sukar untuk mencari semua entiti dalam senarai dengan nilai yang diberikan; anda perlu menggunakan imbasan jadual yang tidak cekap. Anda mungkin perlu menggunakan ungkapan biasa, contohnya dalam MySQL:
idlist REGEXP '[[:<:>:]]' 或在 MySQL 8.0 中：idlist REGEXP '\b2\b'李>
Sukar untuk mengira elemen dalam senarai, atau melakukan pertanyaan pengagregatan lain.
Sukar untuk menyambungkan nilai ke jadual carian yang mereka rujuk.
Sukar untuk mendapatkan senarai dalam susunan yang disusun.
Sukar untuk memilih pembatas yang dijamin tidak akan muncul dalam nilai

Untuk menyelesaikan masalah ini, anda perlu menulis banyak kod aplikasi dan mencipta semula ciri yang lebih cekap yang telah disediakan oleh RDBMS.

Senarai yang dipisahkan koma adalah salah dan saya menjadikannya bab pertama dalam buku saya: SQL Anti-Corak, Jilid 1: Mengelakkan Perangkap Pengaturcaraan Pangkalan Data.

Ada kalanya anda perlu menyahnormalkan, tetapi seperti yang dinyatakan oleh @OMG Ponies, ini adalah pengecualian. Sebarang "pengoptimuman" bukan perkaitan akan memberi manfaat kepada satu jenis pertanyaan dengan mengorbankan penggunaan data yang lain, jadi pastikan anda mengetahui pertanyaan yang memerlukan pengendalian khas supaya pertanyaan tersebut layak untuk dinyahnormalisasi.