Gerçek Dünyada Normalleşme
Veritabanı normalizasyonu kutsal uygulama geliştirme ineklerinden biridir. Almış olduğunuz her lisans programında ya da kitap okudunuz muhtemelen veritabanlarının normalleştirilmesinin önemini vaaz ediyor.
Bu gerçekliğe meydan okuma zamanı. Bazen veritabanınızı denormalize etmek tamamdır!
Ne zaman normalleştirmelisin?
Veri tabanı normalizasyonu, verilerinizin bütünlüğünü korur. Pek çok durumda harika bir fikirdir ve normalleştirme göz önünde bulundurularak herhangi bir veritabanı tasarımı çalışmasına başlamalısınız. Veritabanınızı normalize edebilirseniz, bunun için gidin! Aslında, veritabanınızı bu sitede normalleştirmek için nasıl bazı pratik tavsiyeler:
- Veritabanınızı İlk Normal Formda (1NF) Koyma
- Veritabanınızı İkinci Normal Formda (2NF) koymak
- Veritabanınızı Üçüncü Normal Formda (2NF) koymak
En alt satır, bunu yapmamak için gerçekten iyi bir nedeniniz olmadıkça veritabanınızı normalleştirmeniz gerektiğidir . Normalleştirme genellikle sağlam tasarım pratiğidir. Yedekli bilgileri azaltır, performansı optimize eder ve veritabanınızın farklı köşelerinde saklanan aynı verilere sahip olmanızın sonucu olan veri bütünlüğü sorunlarına sahip olmanız olasılığını azaltır.
Normalize Olmayan Bazı İyi Nedenler
Bu, veritabanınızı normalleştirmemek için bazı iyi nedenler olduğunu söyledi. Bir kaç bakalım:
- Katılırlar pahalıdır . Veritabanınızı normalleştirmek çoğu zaman çok sayıda tablo oluşturmayı içerir. Aslında, beş veya 10 tabloya yayılan basit bir sorgu olması gerektiğini düşündüğünüz şeyle kolayca kayabilirsin. Şimdiye kadar beş masa topluluğuna katılmayı denediyseniz, bunun prensipte çalıştığını biliyorsunuz, ancak pratikte yavaş yavaş. Büyük tablolara yönelik çoklu katılım sorgularına dayanan bir web uygulaması oluşturuyorsanız, kendinizi “Bu veritabanı normalleştirilmemişse!” Diye düşünebilirsiniz. Kafanızda bu düşünceyi duyduğunuzda, Denormalize etmeyi düşün. Veri bütünlüğünü gerçekten tehlikeye atmadan, bu sorgu tarafından kullanılan tüm verileri tek bir tabloya yapıştırabiliyorsanız, bunun için gidin! Bir asi olmak ve veritabanınızı denormalize edin. Geriye bakmayacaksın!
- Normalleştirilmiş tasarım zordur . Karmaşık bir veritabanı şeması ile çalışıyorsanız, muhtemelen kendinizi normalleştirme karmaşıklığı üzerinde masaya karşı başını çarptım bulacaksınız. Basit bir kural olarak, tüm günü, dördüncü normal forma nasıl taşınacağınızı anlamaya çalışıyorsanız, normalleştirmeyi çok uzak tutuyor olabilirsiniz. Geri çekilin ve gerçekten devam etmeye değip değmediğini kendinize sorun.
- Hızlı ve kirli hızlı ve kirli olmalıdır . Sadece bir prototip geliştiriyorsanız, sadece ne olursa olsun çabuk çalışın. Gerçekten mi. Tamam. Hızlı uygulama geliştirme, bazen zarif tasarımdan daha önemlidir. Sadece prototip aşamasının ötesine geçmeye hazır olduğunuzda, geri dönüp tasarımınıza dikkatlice bakmayı unutmayın. Hızlı ve kirli bir veritabanı tasarımı için ödediğiniz fiyat, onu atmanız ve üretime geçme zamanı geldiğinde baştan başlamanız gerektiğidir.
- Bir NoSQL veritabanı kullanıyorsanız , geleneksel normalizasyon arzu edilmez. Bunun yerine, veritabanınızı çok daha bağışlayıcı olan BASE modelini kullanarak tasarlayın. Bu, e-postalar, resimler veya videolar gibi yapılandırılmamış verileri depoladığınızda kullanışlıdır.
Dikkat Bazı Sözler
Veritabanı normalleştirme genellikle iyi bir fikirdir. Bunu yapmak makul göründüğünde normalleşme ilkelerini izlemeyi denemelisiniz. Ancak, tüm göstergeler normalleştirmenin uygulanmayacak kadar karmaşık olduğunu gösteriyorsa, verilerinizi korurken işinizi gerçekleştirecek bir yaklaşımı düşünün.
Son olarak - normalleştirme kurallarından sapmayı seçerseniz, veritabanı bütünlüğünü nasıl zorladığınız konusunda daha dikkatli olun. Yedekli bilgi depolarsanız, bilgilerin tutarlı kaldığından emin olmak için tetikleyicileri ve diğer kontrolleri yerine koyun.