Нормализация базы данных — одна из священных коров разработки приложений. Каждый курс по программированию для студентов или книги, которые вы читали, вероятно, проповедует важность нормализации баз данных .
Пришло время оспорить этот трюизм. Иногда это нормально, чтобы денормализовать вашу базу данных!
Когда следует нормализовать?
Нормализация базы данных защищает целостность ваших данных. Во многих случаях это отличная идея, и начинать разработку базы данных следует с нормализации. Если вы можете нормализовать свою базу данных, сделайте это!
Суть в том, что вам следует нормализовать базу данных, если у вас нет веских причин не делать этого. Нормализация — это обычно правильная практика проектирования. Это уменьшает избыточную информацию, оптимизирует производительность и снижает вероятность того, что у вас возникнут проблемы с целостностью данных, возникающие в результате хранения одних и тех же данных в разных углах базы данных.
Некоторые веские причины не нормализовать
Тем не менее, есть несколько веских причин не нормализовать вашу базу данных. Давайте посмотрим на несколько:
- Соединения стоят дорого . Нормализация вашей базы данных часто включает создание множества таблиц. На самом деле, вы можете легко получить простой запрос, охватывающий пять или десять таблиц. Если вы когда-либо пытались сделать соединение за пятью столами, вы знаете, что это работает в принципе, но на практике это кропотливо медленно. Если вы создаете веб-приложение, которое опирается на запросы множественного объединения для больших таблиц, вы можете подумать: «Если бы только эта база данных не была нормализована!» Когда вы слышите эту мысль в своей голове, самое время подумать о денормализации. Если вы можете поместить все данные, используемые этим запросом, в одну таблицу, не подвергая риску целостность ваших данных, сделайте это! Будьте бунтовщиком и денормализуйте свою базу данных. Ты не оглянешься назад!
- Нормализованный дизайн сложен . Если вы работаете со сложной схемой базы данных , вы, вероятно, столкнетесь с трудностями нормализации. Как простое практическое правило: если вы целый день пытаетесь понять, как перейти к четвертой нормальной форме, возможно, вы слишком далеко зашли бы к нормализации. Отойдите назад и спросите себя, стоит ли продолжать.
- Быстро и грязно должно быть быстро и грязно . Если вы просто разрабатываете прототип, просто делайте все, что работает быстро. В самом деле. Все нормально. Быстрая разработка приложений иногда важнее элегантного дизайна. Просто не забудьте вернуться и внимательно взглянуть на свой дизайн, как только вы будете готовы выйти за рамки стадии прототипирования. Цена, которую вы платите за быстрое и грязное проектирование баз данных, заключается в том, что вам, возможно, придется отказаться от нее и начать все сначала, когда придет время для производства.
- Если вы используете базу данных NoSQL , традиционная нормализация нежелательна. Вместо этого проектируйте свою базу данных, используя модель BASE, которая гораздо более щадящая. Это полезно, когда вы храните неструктурированные данные, такие как электронные письма, изображения или видео.
Несколько слов предостережения
Нормализация базы данных, как правило, хорошая идея. Вы должны стараться следовать принципам нормализации, когда это кажется разумным. Но если все показатели указывают на то, что нормализация слишком сложна для реализации, подумайте о подходе, который позволит выполнить работу, сохраняя при этом ваши данные.
Наконец — если вы решите отклониться от правил нормализации, будьте особенно бдительны в отношении того, как обеспечить соблюдение целостности базы данных. Если вы храните избыточную информацию, поместите триггеры и другие элементы управления на место, чтобы убедиться, что информация остается согласованной.