Нормализация в реалния свят
Нормализирането на базата данни е една от свещените крави при разработването на приложения. Всеки курс за програмиране, който сте взели или сте записали, вероятно проповядва значението на нормализирането на базите данни .
Време е да оспорим този тръз. Понякога е добре да денормализирате базата данни!
Кога трябва да се нормализирате?
Нормализирането на базата данни защитава интегритета на вашите данни. Това е страхотна идея в много случаи и трябва да започнете каквото и да е проектно планиране на базата данни с нормализиране. Ако можете да нормализирате базата данни, отидете за нея! Всъщност, тук са някои практически съвети как да нормализирате базата данни на този сайт:
- Поставяне на базата данни в първия нормален формат (1NF)
- Поставяне на Вашата база данни във втора нормална форма (2NF)
- Поставяне на базата данни в трета нормална форма (2NF)
Най-важното е, че трябва да нормализирате базата данни, освен ако имате сериозна причина да не го направите. Нормализирането обикновено е добра практика при проектирането. Той намалява излишната информация, оптимизира производителността и намалява вероятността да имате проблеми с целостта на данните, които са резултат от това, че същите данни се съхраняват в различни ъгли на вашата база данни.
Някои добри причини да не се нормализира
Това каза, че има някои добри причини да не се нормализира вашата база данни. Нека да разгледаме няколко:
- Присъединяването е скъпо . Нормализирането на вашата база данни често включва създаването на много маси. Всъщност, лесно можете да завършите с това, което според вас трябва да бъде проста заявка, която обхваща пет или 10 таблици. Ако някога сте се опитвали да се присъедините към пет маси, знаете, че тя работи по принцип, но на практика е бавна. Ако създавате уеб приложение, което разчита на заявки за множество присъединявания към големи таблици, може да се окажете, че си мислите: "Ако тази база данни не беше нормализирана!" Когато чуете тази мисъл в главата си, е подходящо време помислете за денормализиране. Ако можете да залепите всички данни, използвани от тази заявка, в една таблица, без наистина да застрашите целостта на данните си, отидете за нея! Бъдете бунтовник и денормализирате базата данни. Няма да погледнете назад!
- Нормализираният дизайн е труден . Ако работите с сложна схема на база данни , най-вероятно ще се окажете, че удряте главата си срещу масата поради сложността на нормализирането. Като просто правило, ако прекарате цял ден, опитвайки се да разберете как да преминете към четвъртата нормална форма, може би сте се нормализирали твърде далеч. Отдръпнете се и се запитайте дали наистина си струва да продължите.
- Бързо и мръсно трябва да бъде бързо и мръсно . Ако просто разработвате прототип, просто правете каквото работи бързо. Наистина ли. ОК е. Бързото разработване на приложения понякога е по-важно от елегантния дизайн. Само не забравяйте да се върнете и внимателно да погледнете дизайна си, след като сте готови да преминете от фазата на създаване на прототипи. Цената, която плащате за бърз и мръсен дизайн на базата данни, е, че може да се наложи да я изхвърлите и да започнете отново, когато е време да се построи за производство.
- Ако използвате NoSQL база данни , традиционната нормализация не е желателна. Вместо това, проектирайте базата си с BASE модел, който е много по-прощаващ. Това е полезно, когато съхранявате неструктурирани данни като имейли, изображения или видеоклипове.
Някои думи на внимание
Обикновено нормализацията на база данни е добра идея. Трябва да се опитате да следвате принципите на нормализиране, когато изглежда разумно да направите това. Но ако всички показатели сочат, че нормализирането е твърде сложно за прилагане, помислете за подход, който ще свърши работата, като същевременно защитава данните ви.
И накрая - ако решите да се отклоните от правилата на нормализирането, бъдете бдителни за начина, по който прилагате целостта на базата данни. Ако съхранявате излишна информация, поставете тригери и други контроли, за да сте сигурни, че информацията остава в съответствие.