Bagaimana saya bisa berdebat dengan meyakinkan terhadap duplikasi kolom database?


47

Saya sudah mulai bekerja di organisasi baru dan salah satu pola yang saya lihat di database adalah menduplikasi bidang untuk membuat pertanyaan penulisan lebih mudah bagi analis bisnis. Kami menggunakan Django dan ORM-nya.

Dalam satu kasus, kami menyimpan objek MedicalRecordNumber dengan string unik yang mengidentifikasi pasien dalam konteks tertentu. Kami memiliki objek Registrasi yang melacak pasien dan telah menghubungkan MedicalRecordNumber , tetapi alih-alih menggunakan hubungan kunci asing, mereka menduplikasi string sehingga mereka dapat menghindari penulisan gabungan ( bukan karena alasan kinerja). Pola ini umum di seluruh basis data.

Bagi saya pentingnya model data menjadi bersih hanya supaya saya bisa memikirkannya dengan baik. Kompleksitas yang tidak perlu adalah pemborosan waktu pemrosesan kognitif saya yang terbatas. Ini masalah sistematis. Tidak nyaman menulis bergabung adalah masalah keterampilan yang dapat diperbaiki. Saya tidak selalu ingin menganjurkan kembali dan mengubah skema, tapi saya ingin dapat dengan meyakinkan mengartikulasikan masalah dengan jenis duplikasi ini.


2
Apa artinya "bergabung dengan tidak nyaman menulis"? Bagaimana mereka menjelaskan hal itu?
scriptin

9
Apakah orang-orang ini bekerja untuk Anda? Apakah Anda penyelia mereka? Sebagian besar justifikasi Anda dapat ditemukan di sini: en.wikipedia.org/wiki/Database_normalization . Ya, mereka harus lebih baik dalam menggunakan gabungan.
Robert Harvey

1
Pernahkah Anda melihat literatur tentang mengapa normalisasi diinginkan?
Nathan Tuggy

17
Tidak akan menambahkan tampilan yang bergabung secara internal membuat permintaan menulis semudah ini? Anda bisa menyarankan mereka sebagai alternatif.
CodesInChaos

1
Apakah Anda mengkomunikasikan hal ini (dengan sopan) dengan teman sebaya Anda? Apa pembenaran mereka, pertimbangan apa yang mereka buat? Ada banyak kemungkinan alasan mengapa ini mungkin ide yang baik (meskipun Anda mengatakan "kinerja bukan alasan", bukti apa yang Anda miliki untuk mendukung itu?). Sebelum menuduh mereka terlalu malas dan / atau kaku, sudahkah Anda mempertimbangkan (dan bertanya) alasan mereka memiliki desain seperti itu? Mungkin ada jauh lebih banyak membaca daripada menulis (analytics DB berat)? Ubah pelacakan? Data historis? Tanyakan semua orang - seseorang mungkin tahu alasan sebenarnya .
Luaan

Jawaban:


128

Basis data operasional Anda harus sangat dinormalisasi, untuk mengurangi anomali .

Basis data analitik (gudang) Anda harus didenormalisasi tinggi, untuk memudahkan analisis.

Jika Anda tidak memiliki database analitik yang terpisah, Anda harus membuat beberapa pandangan [terwujud] yang sangat terdenormalisasi.

Jika Anda memberi tahu analis / manajer bisnis senior Anda untuk melakukan banyak hal untuk analisis sederhana, Anda mungkin akan dipecat.

Agile Data Warehouse Design adalah buku yang bagus

Lihat kiat gudang data cepat dan kotor saya di sini


9
Ini cara yang tepat untuk pergi.
Nit

6
+1 Inilah yang dimaksudkan oleh Tampilan untuk: memungkinkan tampilan terdenormalisasi pada database yang dinormalisasi.
Nzall

4
Benar sekali, tetapi saya pikir "mengurangi anomali" harus lebih ditekankan, karena itulah jawaban utama untuk pertanyaan itu. Anomali yang paling umum (hanya?) Yang akan Anda lihat dengan duplikasi / denormalisasi data adalah bahwa kolom-kolom tersebut entah bagaimana akan diisi dengan data kontradiktif pada saat yang sama, membuat Anda tidak memiliki cara untuk mengetahui apa data yang sebenarnya seharusnya dan tidak ada cara menentukan apa yang salah. Yang terakhir dapat dikurangi dengan pelacakan perubahan besar-besaran, tetapi ini tidak akan murah atau cepat untuk melewati dan menemukan masalahnya. Lebih hemat biaya untuk menghindari masalah sepenuhnya.
jpmc26

2
Sudut lain yang perlu dipertimbangkan adalah bahwa, bahkan dengan asumsi pengembang mampu menjaga data yang benar (ragu-ragu), itu menjadi sumber daya yang sangat besar untuk memastikan bahwa setiap bidang duplikat diperbarui ketika diminta untuk menjaga konsistensi.
Nate CK

1
@Panzercrisis Satu-satunya cara transaksi "implisit" adalah jika Anda memiliki komit otomatis yang berjalan di akhir permintaan Anda. Ini seharusnya tidak menjadi kasus untuk database produksi. Dalam aplikasi, transaksi harus dimulai secara otomatis dan komit harus dikeluarkan secara terpisah dari kueri. Ini adalah investasi kecil di muka dalam aplikasi, tetapi menyederhanakan perubahan kode yang melibatkan penambahan panggilan basis data dan mengurangi seberapa banyak yang harus dipikirkan pengembang (meningkatkan kecepatan dev, mengurangi kesalahan dev). Desain semacam itu juga cocok dengan hal-hal seperti koneksi pooling.
jpmc26

57

Saya mengerti, mengapa seseorang ingin menghindari penulisan join untuk setiap pilih.

Tetapi Anda dapat membuat tampilan sekali dengan bergabung dan menggunakannya bukan tabel yang tidak dinormalisasi Anda.

Jadi, Anda menggabungkan keunggulan normalisasi dengan kenyamanan pilih yang mudah.


12
Tampilan adalah teman Anda. Gunakan mereka secara bebas. Dan untuk kinerja, Anda bahkan bisa menggunakan tampilan Terwujud jika RDBMS Anda mendukungnya.
VH-NZZ

13

Jawaban-jawaban yang telah diupgrade cukup banyak mencakup "cara menghindari duplikasi" (menggunakan tampilan) tetapi bukan alasannya. Mereka pada dasarnya menunjukkan bahwa duplikasi kolom adalah solusi yang salah untuk masalah membuatnya lebih mudah untuk menulis kueri. Tetapi pertanyaan "mengapa tidak menduplikasi kolom acak hanya untuk itu?" masih berdiri.

Jawabannya adalah "Karena Hukum Murphy". Hukum Murphy menyatakan bahwa:

Jika ada yang salah, itu akan terjadi.

Dalam hal ini, konten setiap bidang baris dari kolom duplikat seharusnya identik dengan konten setiap bidang baris yang sesuai dari kolom asli. Apa yang bisa salah, adalah bahwa isi beberapa bidang baris mungkin berbeda dari aslinya, mendatangkan malapetaka. Anda mungkin berpikir bahwa Anda telah mengambil semua tindakan pencegahan yang mungkin untuk memastikan bahwa mereka tidak akan berbeda, tetapi hukum Murphy menyatakan bahwa karena mereka dapat berbeda, mereka akan berbeda. Dan kekacauan akan terjadi.

Sebagai contoh bagaimana ini bisa terjadi, cukup pertimbangkan fakta bahwa kolom yang diduplikasi tidak diisi oleh sihir; seseorang harus benar-benar menulis kode yang menyimpan nilai di dalamnya setiap kali baris dibuat di tabel asli, dan seseorang harus menulis kode yang terus memperbaruinya setiap kali aslinya diubah. Mengesampingkan fakta bahwa ini menambah beban yang tidak semestinya pada kode yang memasukkan data ke dalam basis data, (dan yang, menurut definisi, jauh lebih penting daripada kode apa pun yang hanya menanyakan basis data,) seseorang, di suatu tempat, dalam keadaan tertentu, mungkin lupa untuk melakukan duplikasi ini. Kemudian, nilainya akan berbeda. Atau mereka mungkin ingat untuk melakukan duplikasi, tetapi tidak dalam suatu transaksi, sehingga mungkin, dalam kondisi kesalahan langka tertentu, dihilangkan. Tetapi saya tidak perlu membuang waktu untuk menulis contoh-contoh ini,jika itu bisa salah, itu akan terjadi.


12

Memikirkannya dalam hal pengorbanan daripada yang baik / buruk akan lebih produktif. Mereka menjual keuntungan dari normalisasi (khususnya konsistensi) untuk keuntungan dalam kegunaan permintaan.

Pada satu titik ekstrim, basis data akan menjadi tidak berguna jika data menjadi sangat tidak konsisten. Di sisi lain, basis data akan sia-sia jika terlalu sulit bagi orang-orang yang perlu menanyakannya setiap hari untuk mendapatkan hasil yang dapat mereka andalkan.

Apa yang dapat Anda lakukan untuk mengurangi risiko dan biaya?

  • Bangun alat pemeriksa konsistensi dan jalankan secara teratur.
  • Merutekan akses tulis melalui perangkat lunak yang memperbarui data yang direplikasi secara konsisten.
  • Tambahkan tampilan atau bangun alat kueri yang melakukan penggabungan secara otomatis sehingga pebisnis dapat berpikir dalam hal informasi daripada internal DB.

6

Saya pikir argumen terkuat untuk normalisasi data untuk analis bisnis adalah bahwa ia mempromosikan integritas data. Jika data kunci Anda disimpan hanya di satu tempat (satu kolom, dalam satu tabel), kecil kemungkinan data akan rusak oleh pembaruan yang salah. Saya pikir mereka mungkin akan peduli tentang pentingnya integritas data, jadi ini mungkin cara yang baik untuk meyakinkan mereka untuk memperbarui cara mereka berinteraksi dengan database.

Metode kueri yang sedikit lebih sulit kemungkinan akan lebih disukai daripada potensi korupsi data.


6
Orang-orangnya akan berpendapat bahwa mereka cukup baik untuk memastikan bahwa semua data diperbarui dengan benar (premis yang saya perselisihkan, jika mereka tidak nyaman dengan bergabung). Mungkin argumen yang lebih baik adalah bahwa Anda kehilangan sebagian besar manfaat ACID yang diberikan RDBMS, jika Anda menghindari normalisasi.
Robert Harvey

4
Mungkin, tapi itu semua masalah risiko. Apakah mereka bersedia menerima risiko merusak basis data karena membuat permintaan menjadi lebih mudah?
Oleksi

1
Bermain advokat iblis di sini, argumen tandingan yang jelas adalah bahwa, jika seseorang akan mengacaukan pembaruan dan data yang korup, itu adalah masalah dengan atau tanpa normalisasi - dan, setidaknya, memiliki beberapa redundansi dalam database membuatnya lebih mungkin bahwa seseorang akan melihat korupsi, dan bahkan mungkin dapat memperbaikinya nanti. (Tentu saja, denasionalisasi ad hoc bukanlah skema pendeteksian kesalahan yang paling dapat diandalkan, tetapi prinsip pengecekan kesalahan melalui redundansi adalah masuk akal: begitulah cara pembukuan entri ganda .)
Ilmari Karonen

Atau, dengan kata lain, ada lebih banyak integritas data daripada integritas relasional. Dengan database yang sepenuhnya dinormalisasi, Anda masih dapat mempertahankan integritas relasional yang sempurna bahkan jika seseorang mengacaukan pembaruan, tetapi itu tidak membuat data yang salah diperbarui menjadi sampah.
Ilmari Karonen

0

Untuk menambah apa yang disarankan orang lain di atas. Ini adalah masalah tata kelola data. Anda perlu bekerja dengan pemangku kepentingan yang relevan: arsitek data dan pengelola data untuk mengembangkan prinsip-prinsip data, kebijakan dan konvensi penamaan.

Bersabarlah dan bekerja secara metodis. Perubahan tidak akan terjadi dalam semalam.


0

Berhenti.

Jujur, Anda dapat menghabiskan berbulan-bulan berdebat tentang normalisasi, konsistensi, dan memerangi bug gila yang disebabkan oleh kemalasan belaka, dan kemudian berhenti.

Atau Anda bisa menghemat waktu, frustrasi, dan berhenti sekarang.

Pemrogram yang baik adalah orang yang sangat malas. Mereka memahami kebutuhan pelanggan dan manajemen. Tetapi yang paling penting mereka memahami bahwa menyelesaikan masalah dengan baik, menggunakan solusi yang dirancang dengan baik, dan diimplementasikan dengan baik menyelamatkan mereka secara pribadi dalam jumlah besar , kerja keras, upaya, dan yang terpenting adalah penderitaan dan stres.

Jadi, Anda akan jauh lebih baik bekerja di tempat yang mengerti dan menghargai rekayasa yang baik.

Semoga berhasil.


Afterthought: Mungkin yang mereka butuhkan adalah alat BI / OLAP ... http://en.wikipedia.org/wiki/Online_analytical_processing

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.