Apakah normalisasi basis data mati? [Tutup]

Saya dibesarkan di sekolah lama - tempat kami belajar merancang skema basis data SEBELUM lapisan bisnis aplikasi (atau menggunakan OOAD untuk yang lainnya). Saya sudah cukup baik dengan merancang skema (IMHO :) dan dinormalisasi hanya untuk menghapus redundansi yang tidak perlu tetapi tidak di tempat yang berdampak kecepatan yaitu jika bergabung adalah hit kinerja, redundansi dibiarkan di tempat. Tapi kebanyakan tidak.

Dengan munculnya beberapa kerangka kerja ORM seperti Ruby ActiveRecord atau ActiveJDBC (dan beberapa yang lainnya saya tidak ingat, tapi saya yakin ada banyak) tampaknya mereka lebih suka memiliki kunci pengganti untuk setiap tabel bahkan jika beberapa memiliki kunci primer seperti 'email' - melanggar 2NF secara langsung. Oke, saya mengerti tidak terlalu banyak, tapi itu membuat saya kesal (hampir) ketika beberapa ORM ini (atau programmer) tidak mengakui 1-1 atau 1-0 | 1 (yaitu 1 ke 0 atau 1). Mereka menetapkan bahwa lebih baik memiliki semuanya sebagai satu meja besar tidak masalah jika memiliki satu ton nulls "sistem hari ini dapat mengatasinya" adalah komentar yang sering saya dengar.

Saya setuju bahwa kendala memori memang memiliki korelasi langsung dengan normalisasi (ada manfaat lain juga :) tetapi di zaman sekarang dengan memori murah dan mesin quad-core, apakah konsep normalisasi DB hanya diserahkan pada teks? Sebagai DBA apakah Anda masih mempraktikkan normalisasi ke 3NF (jika tidak BCNF :)? Apakah itu penting? Apakah "skema kotor" bagus untuk sistem produksi? Hanya bagaimana seseorang membuat kasus "untuk" normalisasi jika masih relevan.

( Catatan: Saya tidak berbicara tentang skema bintang / kepingan salju datawarehouse yang memiliki redundansi sebagai bagian / kebutuhan desain tetapi sistem komersial dengan database backend seperti StackExchange misalnya)

Salah satu alasan normalisasi adalah untuk menghapus anomali modifikasi data.
ORM biasanya tidak mendukung ini.

Saya punya banyak contoh database yang dirancang Hibernate yang melanggar prinsip ini:

• bloated (string berulang lebih dari 100 juta baris)
• tidak ada tabel pencarian (lihat di atas)
• tidak ada DRI (kendala, kunci)
• indeks berkerumun varchar
• tabel tautan yang tidak perlu (mis. menegakkan 1..0: 1 ketika kolom FK yang dapat dibatalkan akan mencukupi)

Yang terburuk yang pernah saya lihat adalah database MySQL 1TB yang mungkin 75-80% terlalu besar karena ini

Saya juga menyarankan bahwa pernyataan "sistem todays bisa mengatasinya" adalah benar untuk sebagian besar sistem Mickey Mouse. Ketika Anda mengukur, sistem saat ini tidak akan.

Dalam contoh saya di atas, tidak ada daya tarik untuk refactor atau mengubah kunci atau memperbaiki data: hanya mengeluh tentang tingkat pertumbuhan database dan ketidakmampuan untuk membangun DW yang berarti di atasnya

tampaknya mereka lebih suka memiliki kunci pengganti untuk setiap tabel bahkan jika beberapa memiliki kunci utama seperti 'email' - melanggar 2NF secara langsung.

Kunci pengganti tidak merusak 2NF. 2NF mengatakan "Jika sebuah kolom hanya bergantung pada bagian dari kunci multi-nilai, pindahkan kolom itu ke tabel terpisah."

Mereka menetapkan bahwa lebih baik memiliki semuanya sebagai satu meja besar tidak masalah jika memiliki satu ton nol

Memiliki beberapa kolom dalam satu tabel valid selama aturan Normalisasi diikuti. Tidaklah benar untuk menggabungkan tabel tanpa analisis jika Anda ingin menuai manfaat dari SQL dan normalisasi.

Saya setuju bahwa kendala memori memang memiliki korelasi langsung dengan normalisasi. Relation Normal Forms adalah konsep matematika dan tidak ada hubungannya dengan memori.

Normalisasi ada tidak hanya untuk menghemat memori atau disk, itu ada untuk menambah integritas. Bagaimanapun, ini adalah konsep matematika yang tidak tergantung pada perangkat keras.

Contoh Sederhana: Katakanlah Anda memelihara informasi sekolah sebagai:

Rec 1: Sekolah Menengah North Ridge, California, AS

Rec 2: Sekolah Tinggi Toronto Selatan Braves, Ontario, Kanada

Jika Anda bertanya sistem Anda di mana Ontario, Anda dapat mengetahui bahwa itu di Kanada. Beberapa hari kemudian Anda menghapus baris ke-2 dan menanyakan sistem pertanyaan yang sama dan Anda tidak mendapatkan apa-apa. Dalam contoh ini, tidak peduli berapa banyak ruang disk atau memori atau CPU, Anda tidak akan mendapatkan jawabannya.

Ini adalah salah satu anomali hubungan normalisasi membantu mencegah.

Sunting: Mengubah kata Toronto ke Ontario sesuai komentar di bawah ini.

Semakin banyak hal berubah, semakin mereka tetap sama. Selalu ada pengembang malas yang mengambil jalan pintas atau tidak tahu atau ingin mengikuti praktik terbaik. Banyak waktu mereka bisa lolos dengan itu dalam aplikasi yang lebih kecil.

Dulu menjebak struktur data yang diilhami COBOL ke dalam RDBMS awal, atau kekacauan mengerikan yang dBase. Sekarang ORM dan "Code-First". Pada akhirnya, ini semua hanyalah cara orang yang berusaha menemukan peluru perak untuk mendapatkan sistem kerja tanpa "membuang" waktu berpikir keras tentang apa yang Anda inginkan dan perlu lakukan. Terburu-buru selalu menjadi masalah dan akan selalu menjadi masalah.

Bagi mereka yang memiliki akal sehat (dan keberuntungan) untuk meluangkan waktu untuk merancang dengan benar, model data akan selalu menjadi tempat yang paling logis untuk memulai. Apa yang ada di dalam database adalah informasi tentang hal-hal (berwujud dan tidak berwujud) yang menjadi perhatian bisnis Anda. Apa yang diperhatikan bisnis Anda terhadap perubahan jauh lebih cepat daripada cara bisnis Anda beroperasi. Inilah sebabnya mengapa basis data Anda umumnya jauh lebih stabil daripada kode Anda.

Basis data adalah fondasi yang tepat dari sistem apa pun dan meluangkan waktu untuk meletakkan fondasi Anda dengan benar akan menguntungkan Anda dalam jangka panjang. Itu berarti normalisasi akan selalu menjadi langkah penting dan berguna untuk aplikasi tipe OLTP apa pun.

Saya setuju bahwa kendala memori memang memiliki korelasi langsung dengan normalisasi ...

Kendala memori masih penting. Kuantitas bukan masalah, kecepatan.

• CPU tidak menjadi lebih cepat saat ini (Kami mendapatkan lebih banyak inti, bukan siklus per detik)
• Arsitektur CPU modern berupaya mengatasi batasan kecepatan dengan menyediakan memori terpisah untuk setiap prosesor ( NUMA ).
• Ukuran cache on-die tidak tumbuh pada tingkat yang sebanding dengan memori utama.
• Throughput memori tidak setinggi yang diharapkan kebanyakan orang. QPI berada di wilayah 25GB / detik.

Beberapa dari tanah ini tercakup dalam Kapan menggunakan TINYINT melalui INT? yang mungkin berguna bagi Anda. Saya juga menyarankan mengikuti kejenakaan @ThomasKejser ( blog ) dari tim SQLCAT, karena mereka cenderung berada di ujung tajam mendorong kinerja database. Posting terbaru tentang Pengaruh Cache CPU dan Pola Akses Memori dan presentasi SQLBits tentang Pemodelan Relasional untuk Skala DW Ekstrim adalah contoh yang baik.

Menurut pendapat saya, ini masih tentang keseimbangan antara normalisasi & de-normalisasi . Saya sepenuhnya setuju bahwa kerangka kerja ORM hanyalah pendekatan untuk menyelesaikan sesuatu, tetapi saya tidak berpikir kerangka inilah yang menyebabkan tren de-normalisasi .

masih perdebatan bahwa Anda ingin efisiensi waktu atau Anda ingin efisiensi ruang. Pada saat teori Database Relasional diangkat, penyimpanan disk mahal, orang jelas tidak ingin menghabiskan banyak uang untuk ini, itu sebabnya pada saat itu database relasional adalah orang yang berdiri teguh di tengah kesulitan

Sekarang hal-hal sangat berbeda, penyimpanan sangat sangat murah. Jadi jelas kita bisa mentolerir redundansi lebih banyak dibandingkan dengan masa lalu, ini juga MENGAPA pendekatan BIG_TABLE muncul. untuk mencari lebih banyak efisiensi waktu, efisiensi ruang harus dikorbankan.

Tapi, pendekatan Big-table bukanlah akhir dari cerita, masih keseimbangan antara waktu dan ruang, dalam hal volume data PB untuk dikelola, beberapa pengembang juga mulai mencari keseimbangan kembali ke efisiensi ruang, itu sebabnya ada adalah pekerjaan yang dilakukan untuk menormalkan beberapa data dalam struktur seperti BIG-TABLE.

Singkatnya, pendekatan normalisasi tidak mati pasti, tetapi dibandingkan dengan masa lalu itu pasti diabaikan.

CJ Date menjawab pertanyaan Anda di sini - video normalisasi (pendahuluan) gratis.

http://shop.oreilly.com/product/0636920025900.do

Jawaban singkatnya: normalisasi adalah cara yang benar secara matematis dalam melakukan sesuatu. Jika Anda tidak menormalkan dengan benar, model data Anda tidak benar.