Veritabanı normalleştirmesi öldü mü? [kapalı]

Uygulamanın iş katmanından ÖNCE (veya her şey için OOAD kullanarak) veritabanı şemasını tasarlamayı öğrendiğimiz eski okulu büyüttüm. Şemaları (IMHO :) tasarlama konusunda oldukça iyiyim ve sadece gereksiz yedekliliği kaldırmak için normalleştirildim, ancak hızı etkilediği yerde değil, yani birleşimler bir performans isabetiyse, yedeklilik yerinde kaldı. Ama çoğunlukla öyle değildi.

Ruby'nin ActiveRecord veya ActiveJDBC gibi bazı ORM çerçevelerinin ortaya çıkmasıyla (ve hatırlayamadığım birkaç tane, ama eminim bol var) bazı birincil anahtarlar olsa bile her tablo için bir yedek anahtara sahip olmayı tercih ediyor gibi görünüyor 'email' - 2NF'yi açıkça kırma. Tamam, çok fazla anlamadım, ancak bu ORM'lerin (veya programcıların) 1-1 veya 1-0 | 1'i (yani 1 ila 0 veya 1) kabul etmediği zaman sinirleri alır (neredeyse). Onlar bir ton nulls "bugünün sistemleri halledebilir" olursa olsun, her şeyi tek bir büyük tablo olarak sahip olmak daha iyi olduğunu daha sık duydum yorumdur.

Bellek kısıtlamalarının normalleşmeyle doğrudan bir korelasyonu olduğunu kabul ediyorum (başka faydaları da var :) ama günümüzde ucuz bellek ve dört çekirdekli makinelerle DB normalleştirme kavramı metinlere bırakıldı mı? DBA'lar olarak hala 3NF'ye normalleştirme uyguluyor musunuz (BCNF değilse)? Önemli mi? "Kirli şema" tasarımı üretim sistemleri için iyi midir? Eğer hala konuyla ilgiliyse, normalleştirme durumu "nasıl" yapmalıdır.

( Not: Tasarımın bir parçası / ihtiyacı olarak artıklık içeren datawarehouse'un yıldız / kar tanesi şemalarından değil, örneğin StackExchange gibi bir arka uç veritabanına sahip ticari sistemlerden bahsetmiyorum)

Normalleştirmenin bir nedeni, veri değiştirme anormalliklerini ortadan kaldırmaktır
ORM'ler genellikle bunu desteklemez.

Bu ilkeyi ihlal eden Hibernate tarafından tasarlanmış veritabanlarının birçok örneğim var:

• şişirilmiş (100 milyon satırın üzerinde tekrarlanan dize)
• arama tablosu yok (yukarıya bakın)
• DRI yok (kısıtlamalar, anahtarlar)
• varchar kümelenmiş dizinleri
• gereksiz bağlantı tabloları (örneğin, boş bir FK sütunu yeterli olduğunda zorlama 1..0: 1)

Gördüğüm en kötüsü, belki de% 75-80 çok büyük olan 1 TB MySQL veritabanı.

Ayrıca "bugünün sistemleri işleyebilir" ifadesinin çoğu Mickey Mouse sistemi için geçerli olduğunu da öneririm. Ölçekledikçe, bugünün sistemleri olmayacak.

Yukarıdaki örneğimde, yeniden düzenleme veya anahtarları değiştirme veya verileri düzeltme konusunda herhangi bir çekiş yoktu: sadece veritabanı büyüme hızlarından ve bunun üzerine anlamlı bir DW oluşturma konusunda şikayetçi oldum

bazılarının 'e-posta' gibi birincil anahtarları olsa bile, 2NF'yi açıkça kırarak her tablo için bir yedek anahtar kullanmayı tercih ettikleri anlaşılıyor.

Yedek anahtarlar 2NF'yi bozmaz. 2NF, "Bir sütun çok değerli bir anahtarın yalnızca bir bölümüne bağlıysa, bu sütunu ayrı bir tabloya kaldırın."

Tonlarca boş olursa olsun, her şeyi büyük bir masa olarak almanın daha iyi olduğunu şart koşarlar.

Bir tabloda birden çok sütun bulunması, Normalleştirme kurallarına uyulduğu sürece geçerlidir. SQL ve normalizasyonun avantajlarından yararlanmak istiyorsanız tabloları analiz yapmadan birleştirmek doğru değildir.

Bellek kısıtlamalarının normalleşmeyle doğrudan bir korelasyonu olduğunu kabul ediyorum. İlişkiler Normal Formlar matematiksel bir kavramdır ve bellekle ilgisi yoktur.

Normalleştirme sadece bellek veya diski kaydetmek için değil, bütünlük eklemek için de vardır. Sonuçta, donanımdan bağımsız bir matematiksel kavramdır.

Basit Örnek: Okul bilgilerini şu şekilde sakladığınızı varsayalım:

Rec 1: North Ridge Lisesi, Kaliforniya, ABD

Rec 2: Güney Toronto Braves Lisesi, Ontario, Kanada

Sisteminize Ontario'nun nerede olduğunu sorarsanız, bunun Kanada'da olduğunu öğrenebilirsiniz. Birkaç gün sonra 2. satırı siler ve sisteme aynı soruyu sorarsınız ve hiçbir şey almazsınız. Bu örnekte, ne kadar disk alanı veya bellek veya CPU olursa, cevabı alamayacaksınız.

Bu, ilişkilerin normalleştirilmesine yardımcı olan bir anomali.

Düzenleme: Aşağıdaki yoruma göre Toronto kelimesini Ontario'ya değiştirdi.

Ne kadar çok şey değişirse, o kadar fazla kalırlar. Köşeleri kesen veya sadece en iyi uygulamaları bilmeyen veya takip etmek istemeyen tembel geliştiriciler her zaman olmuştur. Çoğu zaman daha küçük uygulamalarda ondan kurtulabilirler.

Eskiden COBOL'dan esinlenen veri yapılarını erken RDBMS'ye ya da dBase olan Tanrı korkunç karmaşaya sıkıştırıyordu. Şimdi ORM'ler ve "Önce Kod". Sonunda, bunların hepsi, ne istediğinizi ve ne yapmanız gerektiğini çok düşünmeden zaman kaybetmeden bir çalışma sistemi elde etmenin gümüş mermisini bulmaya çalışan insanların sadece yollarıdır. Acele etmek her zaman bir sorun olmuştur ve her zaman bir sorun olacaktır.

İyi bir tasarıma (ve iyi şansa) sahip olanlar için doğru bir şekilde tasarım yapmak için zaman ayırın, veri modeli her zaman başlamak için en mantıklı yer olacaktır. Veritabanına giren şey, işletmenizin önem verdiği şeyler hakkında (somut ve soyut) bilgilerdir. Ne çok daha az hızlı daha değişikliklerle ilgili iş umurunda nasıl iş çalışır. Bu nedenle veritabanınız genellikle kodunuzdan çok daha kararlıdır.

Veritabanı herhangi bir sistemin doğru temelidir ve vakıflarınızı uygun şekilde yerleştirmek için zaman ayırmak kaçınılmaz olarak uzun vadede size fayda sağlayacaktır. Bu normalleşmenin her türlü OLTP tipi uygulama için her zaman önemli ve faydalı bir adım olacağı anlamına gelir.

Bellek kısıtlamalarının normalleşmeyle doğrudan bir korelasyonu olduğunu kabul ediyorum ...

Bellek kısıtlamaları hala önemlidir. Miktar sorun değil, hız.

• CPU'lar şu anda daha hızlı hale gelmiyor (Saniyede döngü değil, daha fazla çekirdek alıyoruz)
• Modern CPU mimarileri, her işlemci ( NUMA ) için ayrı bellek sağlayarak hız sınırlamasını aşmaya çalışır .
• Kalıpta önbellek boyutları, ana bellekle karşılaştırılabilir bir oranda büyümiyor.
• Bellek hacmi çoğu insanın beklediği kadar yüksek değildir. QPI , 25GB / sn civarındadır.

Bu zeminin bir kısmı TINYINT ne zaman INT üzerinde kullanılır? yararlı bulabilirsiniz. Ben de veritabanı performansını itme keskin kenarında olma eğiliminde olduğu için, SQLCAT ekibinden @ThomasKejser ( blog ) antics takip etmenizi öneririz . CPU Önbelleklerinin ve Bellek Erişimi Desenlerinin Etkisi ve SQLBits sunumu Aşırı DW Ölçeği için İlişkisel Modelleme üzerine son yazı iyi örneklerdir.

Kanımca, hala normalleştirme ve normalleştirme arasındaki denge hakkında . ORM çerçevelerinin sadece işlerin yapılmasına yönelik yaklaşımlar olduğuna tamamen katılıyorum, ancak normalleştirme eğilimine neden olan bu çerçeveler olduğunu düşünmüyorum .

yine de zaman verimliliği veya alan verimliliği istiyorsunuz. İlişkisel Veritabanı teorisi ortaya çıktığında, disk depolama pahalıdır, insanlar açıkçası bu kadar para harcamak istemezler, bu yüzden ilişkisel veritabanları olumsuzluklar arasında sağlam olanlardır

Şimdi günler oldukça farklı, depolama çok ucuz. Açıkçası, eski günlere kıyasla daha fazla yedekliliği tolere edebiliriz, bu da BIG_TABLE yaklaşımının neden ortaya çıktığıdır. daha fazla zaman verimliliği elde etmek için, alan verimliliği feda edilmelidir.

Ancak, Big-table yaklaşımı hikayenin sonu değil, yine de zaman ve mekan arasındaki denge, yönetilecek PB hacim verileri açısından, bazı geliştiriciler de alan verimliliğine geri denge aramaya başladı, bu yüzden orada BIG-TABLE benzeri yapılardaki bazı verileri normalleştirmek için yapılan çalışmalardır.

Tek kelimeyle, normalleşme yaklaşımı kesinlikle ölü değildir, ancak eski günlerle karşılaştırıldığında kesinlikle göz ardı edilir.

CJ Date sorunuzu burada yanıtlıyor - normalleştirme (prelim) videosu ücretsiz.

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

Kısa cevap: normalleştirme, işleri yapmanın matematiksel olarak doğru yoludur. Düzgün normalleştirmezseniz, veri modeliniz yanlıştır.