tabel tetap tunggal dengan banyak kolom vs tabel abstrak fleksibel

Masalah tertentu perlu diklarifikasi dan diselesaikan sebelum kita bisa masuk ke dalam diskusi yang masuk akal.

Resolusi Prasyarat

Label
Dalam profesi yang menuntut ketepatan, penting bagi kita untuk menggunakan label yang tepat, untuk menghindari kebingungan, dan agar kita dapat berkomunikasi tanpa harus menggunakan deskripsi dan kualifikasi yang bertele-tele.

Apa yang Anda poskan sebagai Tabel Tetap, Tidak Normal . Cukup adil, ini mungkin merupakan upaya dalam bentuk Normal Ketiga, tetapi sebenarnya itu adalah file datar, Tidak dinormalisasi (bukan "dinormalisasi). Apa yang telah Anda posting sebagai AbstractTables, tepatnya, Entity-Attribute-Value , yang hampir, tetapi tidak cukup, bentuk Normal Keenam, dan karena itu lebih dinormalisasi daripada 3NF. Dengan asumsi itu dilakukan dengan benar, tentu saja.

File datar yang tidak dinormalisasi tidak "didenormalisasi". Ini penuh dengan duplikasi (tidak ada yang dilakukan untuk menghapus grup berulang dan kolom duplikat atau untuk menyelesaikan dependensi) dan Nulls, ini adalah kinerja babi dalam banyak hal, dan mencegah konkurensi.

Untuk Denormalisasi, pertama-tama harus dinormalisasi, dan kemudian Normalisasi mundur sedikit untuk beberapa alasan yang baik. Karena tidak dinormalisasi di tempat pertama, itu tidak dapat didenormalisasi. Ini hanya Tidak Dinormalisasi.

Itu tidak dapat dikatakan didenormalisasi "untuk kinerja", karena menjadi babi kinerja, itu adalah kebalikan dari kinerja. Yah, mereka membutuhkan pembenaran untuk kurangnya desain formal], dan "untuk kinerja" adalah itu. Bahkan pemeriksaan formal terkecil pun mengungkap representasi yang salah (tetapi sangat sedikit orang yang dapat memberikannya, sehingga tetap tersembunyi, sampai mereka mendapatkan orang luar untuk mengatasi, Anda dapat menebaknya, masalah kinerja yang sangat besar).

Struktur yang dinormalisasi berkinerja jauh lebih baik daripada struktur yang tidak dinormalisasi. Struktur yang lebih dinormalisasi (EAV/6NF) berkinerja lebih baik daripada struktur yang kurang dinormalisasi (3NF/5NF).

Saya setuju dengan dorongan OMG Ponies, tetapi tidak dengan label dan definisinya

daripada mengatakan 'jangan "denormalisasi" kecuali Anda harus' , saya mengatakan, 'Normalkan dengan setia, titik' dan 'jika ada masalah kinerja, Anda belum melakukan Normalisasi dengan benar' .

Wikipedia
Entri untuk Bentuk Normal dan Normalisasi menawarkan definisi yang salah; mereka mengacaukan Bentuk Normal; mereka kurang mengenai proses Normalisasi; dan mereka memberikan bobot yang sama pada NF yang tidak masuk akal atau dipertanyakan yang telah dibantah sejak lama. Hasilnya, Wikipedia menambah topik yang sudah membingungkan dan jarang dipahami. Jadi jangan buang waktu Anda.

Namun, untuk kemajuan, tanpa referensi yang menjadi penghalang, izinkan saya mengatakan ini.

Definisi 3NF stabil, dan tidak berubah.

Ada banyak kebingungan NF antara 3NF dan 5NF. Yang benar adalah bahwa ini adalah area yang berkembang selama 15 tahun terakhir; dan banyak organisasi, akademisi serta vendor dengan produk mereka dengan keterbatasan, melompat untuk membuat "Bentuk Normal" baru untuk memvalidasi penawaran mereka. Semua melayani kepentingan komersial dan secara akademis tidak sehat. 3NF dalam keadaan aslinya yang tidak dirusak dimaksudkan dan menjamin atribut tertentu.

Jumlah totalnya adalah, 5NF adalah hari ini, yang dimaksudkan sebagai 3NF 15 tahun yang lalu, dan Anda dapat melewati olok-olok komersial dan dua belas atau lebih NF "khusus" (komersial dan pseudo-akademik) di antaranya, beberapa yang diidentifikasi di Wikipedia, dan bahkan dalam istilah yang membingungkan.

Bentuk Normal Kelima
Karena Anda sudah bisa memahami dan mengimplementasikan EAV di postingan Anda, Anda tidak akan kesulitan memahami hal-hal berikut. Tentu saja Model Relasional yang benar adalah prasyarat, kunci yang kuat, dll. Bentuk Normal Kelima adalah, karena kita melewatkan Keempat:

Bentuk Normal Ketiga

yang secara definitif sederhana adalah, setiap kolom bukan kunci di setiap tabel memiliki hubungan 1::1 dengan Kunci Utama tabel,

dan tidak ke kolom non-kunci lainnya

Nol duplikasi data (hasilnya, jika Normalisasi dikembangkan dengan rajin; tidak dicapai dengan kecerdasan atau pengalaman saja, atau dengan bekerja ke arah itu sebagai tujuan tanpa proses formal)

tidak Perbarui Anomali (bila Anda memperbarui kolom di suatu tempat, Anda tidak perlu memperbarui kolom yang sama yang terletak di tempat lain; kolom ada di satu dan hanya satu tempat).

Jika Anda memahami hal di atas, 4NF, BCNF, dan semua "NF" konyol dapat diabaikan, mereka diperlukan untuk Sistem Pengarsipan Catatan fisik, seperti yang dipromosikan oleh akademisi, cukup asing bagi Model Relasional (Codd).

Bentuk Normal Keenam

Tujuannya adalah menghapus data yang hilang (kolom atribut), alias penghapusan Nulls

Ini adalah satu-satunya solusi yang benar untuk Masalah Null (juga disebut Menangani Nilai yang Hilang), dan hasilnya adalah database tanpa Nulls. (Hal ini dapat dilakukan pada 5NF dengan standar dan pengganti Null tetapi itu tidak optimal.) Bagaimana Anda menafsirkan dan menampilkan nilai yang hilang adalah cerita lain.

Secara teknis, bukan Bentuk Normal yang sebenarnya, karena tidak memiliki 5NF sebagai prasyarat, tetapi memiliki nilai

Bentuk Normal EAV vs Keenam
Semua database yang saya tulis, kecuali satu, adalah murni 5NF. Saya telah bekerja dengan (dikelola, diperbaiki, ditingkatkan) beberapa database EAV, dan saya telah menerapkan banyak database 6NF benar. EAV adalah implementasi longgar dari 6NF, sering dilakukan oleh orang-orang yang tidak memiliki pemahaman yang baik tentang Normalisasi dan NF, tetapi yang dapat melihat nilai, dan membutuhkan fleksibilitas, EAV. Anda adalah contoh sempurna.

Perbedaannya adalah ini:karena longgar, dan karena pelaksana tidak memiliki referensi (6NF) untuk setia, mereka hanya mengimplementasikan apa yang mereka butuhkan, dan mereka menulis semuanya dalam kode; yang akhirnya menjadi model yang tidak konsisten.

Padahal, implementasi 6NF murni memang memiliki titik referensi akademis murni, dan karenanya biasanya lebih ketat, dan konsisten. Biasanya ini muncul dalam dua elemen yang terlihat:

6NF memiliki katalog yang berisi metadata, dan semuanya didefinisikan dalam metadata, bukan kode. EAV tidak memilikinya, semuanya ada dalam kode (pelaksana melacak objek dan atribut). Jelas sebuah katalog memudahkan penambahan kolom, navigasi, dan memungkinkan utilitas untuk dibentuk.

6NF jika dipahami, memberikan solusi sebenarnya untuk Masalah Null. Pelaksana EAV, karena mereka tidak memiliki konteks 6NF, menangani data yang hilang dalam kode, secara tidak konsisten, atau lebih buruk, mengizinkan Nulls dalam database. Pelaksana 6NF melarang Nulls, dan menangani Data yang hilang secara konsisten dan elegan, tanpa memerlukan konstruksi kode (untuk penanganan Null; Anda tetap harus membuat kode untuk data yang hilang tentunya).

Misalnya. Untuk database 6NF dengan katalog, saya memiliki satu set procs yang akan [kembali] menghasilkan SQL yang diperlukan untuk melakukan semua SELECT, dan saya menyediakan Tampilan dalam 5NF untuk semua pengguna, sehingga mereka tidak perlu mengetahui atau memahami struktur 6NF yang mendasarinya . Mereka diusir dari katalog. Dengan demikian perubahan menjadi mudah dan otomatis. Tipe EAV melakukannya secara manual, karena tidak adanya katalog.

Diskusi

Sekarang, kita bisa memulai diskusi.

"Tentu saja bisa lebih abstrak jika nilai sudah ditentukan sebelumnya (Contoh:spesialisasi dapat memiliki daftarnya sendiri)"

Tentu. Tapi jangan terlalu "abstrak". Pertahankan konsistensi dan terapkan daftar tersebut dengan cara EAV (atau 6NF) yang sama seperti daftar lainnya.

"Jika saya mengambil pendekatan abstrak, ini bisa sangat fleksibel, tetapi kueri akan lebih kompleks dengan banyak gabungan. Tapi saya tidak tahu apakah ini memengaruhi kinerja, mengeksekusi kueri 'lebih kompleks' ini."

Bergabung adalah pejalan kaki dalam database relasional. Masalahnya bukan pada database, masalahnya adalah SQL rumit saat menangani gabungan, terutama kunci majemuk.

Basis data EAV dan 6NF memiliki lebih banyak Gabung, yang sama seperti pejalan kaki, tidak lebih, tidak kurang. Jika Anda harus mengkodekan setiap SELECT secara manual, tentu saja, yang rumit menjadi sangat tidak praktis.

Seluruh masalah dapat dihilangkan dengan (a) menggunakan 6NF melalui EAV dan (b) menerapkan katalog, dari mana Anda dapat (c) menghasilkan semua SQL dasar. Menghilangkan seluruh kelas kesalahan juga.

Ini adalah mitos umum bahwa bergabung entah bagaimana memiliki biaya. Benar-benar salah.

Penggabungan diimplementasikan pada waktu kompilasi, tidak ada substansi untuk 'membiayai' siklus CPU.

Masalahnya adalah ukuran tabel bergabung, bukan biaya Gabung antara tabel yang sama.

Menggabungkan dua tabel dengan jutaan baris masing-masing, pada relasi PK⇢FK yang benar, masing-masing memiliki indeks yang sesuai
(Unik pada sisi induk [PK]; Unik pada sisi Anak [PK=induk FK + sesuatu]
seketika

Di mana indeks Anak tidak unik, tetapi setidaknya kolom utama valid, itu lebih lambat; di mana tidak ada indeks yang berguna, tentu saja sangat lambat.

Tidak ada hubungannya dengan biaya Gabung.

Di mana banyak baris dikembalikan, hambatannya adalah jaringan dan tata letak disk; bukan pemrosesan bergabung.

Oleh karena itu Anda bisa mendapatkan "kompleks" yang Anda inginkan, tanpa biaya, SQL dapat menanganinya.

Saya akan tertarik untuk mengetahui apa kelebihan dan kekurangan dari kedua metode tersebut. Saya hanya dapat membayangkannya sendiri, tetapi saya tidak memiliki pengalaman untuk mengonfirmasi hal ini.

5NF (atau 3NF untuk mereka yang belum membuat kemajuan) adalah yang termudah dan terbaik, dalam hal implementasi; kemudahan penggunaan (pengembang sekaligus pengguna); dan pemeliharaan.

Kekurangannya, setiap kali Anda menambahkan kolom, Anda harus mengubah struktur database (tabel DDL). Itu baik-baik saja dalam beberapa kasus, tetapi tidak dalam banyak kasus, karena kontrol perubahan di tempat, cukup berat.

Kedua, Anda harus mengubah kode yang ada (penanganan kode kolom baru tidak dihitung, karena itu adalah keharusan):di mana standar yang baik diterapkan, itu diminimalkan; di mana mereka tidak ada, cakupannya tidak dapat diprediksi.

EAV (yang telah Anda posting), memungkinkan kolom ditambahkan tanpa perubahan DDL. Itulah satu-satunya alasan orang memilihnya. (penanganan kode kolom baru tidak masuk hitungan, karena itu suatu keharusan). Jika diterapkan dengan baik, itu tidak akan mempengaruhi kode yang ada; jika tidak, itu akan terjadi.

Tetapi Anda membutuhkan pengembang berkemampuan EAV.

Ketika EAV diimplementasikan dengan buruk, itu sangat buruk, kekacauan yang lebih buruk daripada 5NF yang dilakukan dengan buruk, tetapi tidak lebih buruk dari Unnormalised yang merupakan kebanyakan database di luar sana (disalahartikan sebagai "denormalisasi untuk kinerja").

Tentu saja, bahkan lebih penting (daripada di 5NF/3NF) untuk memiliki konteks Transaksi yang kuat, karena kolomnya jauh lebih terdistribusi.

Demikian juga, penting untuk mempertahankan Integritas Referensial Deklaratif:kekacauan yang saya lihat sebagian besar disebabkan oleh pengembang yang menghapus DRI karena menjadi "terlalu sulit untuk dipertahankan", hasilnya, seperti yang dapat Anda bayangkan, satu ibu tumpukan data dengan duplikat baris dan kolom 3NF/5NF di semua tempat. Dan penanganan Null yang tidak konsisten.

Tidak ada perbedaan kinerja, dengan asumsi bahwa server telah dikonfigurasi secara wajar untuk tujuan yang dimaksudkan. (Oke, ada pengoptimalan khusus yang hanya mungkin dilakukan di 6NF, yang tidak mungkin dilakukan di NF lain, tapi saya pikir itu di luar cakupan utas ini.) Dan lagi, EAV yang dilakukan dengan buruk dapat menyebabkan kemacetan yang tidak perlu, tidak lebih dari Tidak dinormalisasi.

Tentu saja, jika Anda menggunakan EAV, saya merekomendasikan lebih banyak formalitas; membeli pound penuh; pergi dengan 6NF; menerapkan katalog; utilitas untuk menghasilkan SQL; Tampilan; menangani Data Hilang secara konsisten; menghilangkan Nulls sama sekali. Ini mengurangi kerentanan Anda terhadap kualitas pengembang Anda; mereka dapat melupakan masalah esoteris EAV/6NF, menggunakan Tampilan, dan berkonsentrasi pada logika aplikasi.