Нормализация базы данных мертва? [закрыто]

Я был воспитан в старой школе - где мы научились проектировать схему базы данных ДО бизнес-уровня приложения (или использовать OOAD для всего остального). Я был довольно хорош в разработке схем (IMHO :) и нормализовался только для удаления ненужной избыточности, но не там, где это влияло на скорость, т. Е. Если объединения были снижением производительности, избыточность оставалась на месте. Но в основном это было не так.

С появлением некоторых сред ORM, таких как ActiveRecord в Ruby или ActiveJDBC (и некоторых других, которые я не могу вспомнить, но я уверен, что их много), кажется, что они предпочитают иметь суррогатный ключ для каждой таблицы, даже если у некоторых есть первичные ключи, такие как «электронная почта» - сломать 2NF сразу. Хорошо, я понимаю не слишком много, но это действует мне на нервы (почти), когда некоторые из этих ORM (или программистов) не признают 1-1 или 1-0 | 1 (то есть 1 к 0 или 1). Они утверждают, что лучше иметь все как одну большую таблицу, независимо от того, есть ли у нее тонна nulls «сегодняшние системы могут с ней справиться» - это комментарий, который я слышал чаще.

Я согласен, что ограничения памяти имели прямую связь с нормализацией (есть и другие преимущества :), но в наше время с дешевой памятью и четырехъядерными машинами концепция нормализации БД оставлена ​​только текстам? Как администраторы баз данных вы все еще практикуете нормализацию до 3NF (если не BCNF :)? Это имеет значение? Хороший ли дизайн «грязной схемы» для производственных систем? Только как следует обосновать «нормализацию», если она все еще актуальна.

( Примечание: я не говорю о схемах типа «звезда / снежинка» хранилища данных, которые имеют избыточность как часть / необходимость проектирования, а о коммерческих системах с внутренней базой данных, такой как StackExchange, например)

Одной из причин нормализации является устранение аномалий изменения данных, которые
ORM обычно не поддерживают.

У меня есть много примеров баз данных, разработанных Hibernate, которые нарушают этот принцип:

• раздутый (строка повторяется более 100 миллионов строк)
• нет таблиц поиска (см. выше)
• нет DRI (ограничения, ключи)
• varchar кластерные индексы
• таблицы ненужных ссылок (например, принудительное применение 1..0: 1, когда достаточно пустого столбца FK)

Худшее, что я видел, - это база данных MySQL объемом 1 ТБ, которая была, возможно, слишком большой на 75-80%.

Я бы также предположил, что утверждение «современные системы могут справиться с этим» верно для большинства систем Mickey Mouse. По мере масштабирования сегодняшние системы не будут.

В моем примере выше не было тяги к рефакторингу или изменению ключей или исправлению данных: просто жаловались на темпы роста базы данных и неспособность построить значимый DW поверх этого

кажется, что они предпочитают иметь суррогатный ключ для каждой таблицы, даже если у некоторых есть первичные ключи, такие как «электронная почта», что напрямую нарушает 2NF.

Суррогатные ключи не ломают 2NF. 2NF говорит: «Если столбец зависит только от части многозначного ключа, удалите этот столбец в отдельную таблицу».

Они предусматривают, что лучше иметь все как один большой стол, независимо от того, есть ли у него тонна нулей

Наличие нескольких столбцов в одной таблице допустимо при условии соблюдения правил нормализации. Неправильно объединять таблицы без анализа, если вы хотите воспользоваться преимуществами SQL и нормализации.

Я согласен, что ограничения памяти имели прямую связь с нормализацией. Нормальные формы отношений - это математическая концепция, которая не имеет ничего общего с памятью.

Нормализация - это не только сохранение памяти или диска, но и добавление целостности. В конце концов, это математическая концепция, независимая от аппаратного обеспечения.

Простой пример: скажем, вы сохраняете информацию о школе как:

Рек 1: Средняя школа Норт Ридж, Калифорния, США

Рек 2: Средняя школа Южной Торонто Бравс, Онтарио, Канада

Если вы спросите свою систему, где находится Онтарио, вы можете узнать, что она находится в Канаде. Через несколько дней вы удаляете 2-й ряд и задаете тот же вопрос системе, и вы ничего не получаете. В этом примере, независимо от того, сколько места на диске или памяти или процессора, вы не получите ответ.

Эту аномалию нормализуют отношения, помогают предотвратить.

Изменить: изменил слово Торонто на Онтарио, как в комментарии ниже.

Чем больше вещи меняются, тем больше они остаются неизменными. Всегда были ленивые разработчики, которые срезали углы, или просто не знают или хотят следовать лучшим практикам. Большую часть времени они могут сойти с рук в небольших приложениях.

Раньше это было засовывание вдохновленных COBOL структур данных в ранние RDBMS или ужасный беспорядок, который был dBase. Теперь это ORMs и «Code-First». В конце концов, это всего лишь способы, с помощью которых люди пытаются найти серебряную пулю получения работающей системы, не «тратя» время на тщательное размышление о том, что вы хотите и что должны делать. Быть в спешке всегда было проблемой и всегда будет проблемой.

Для тех, у кого есть здравый смысл (и удача) потратить время на правильное проектирование, модель данных всегда будет наиболее логичным местом для начала. В базе данных содержится информация о вещах (материальных и нематериальных), о которых заботится ваш бизнес. То, что заботится о вашем бизнесе, меняется гораздо быстрее, чем то, как работает ваш бизнес. Вот почему ваша база данных, как правило, гораздо более стабильна, чем ваш код.

База данных является законной основой любой системы, и если вы потратите время на то, чтобы заложить основы должным образом, это неизбежно принесет вам пользу в долгосрочной перспективе. Это означает, что нормализация всегда будет важным и полезным шагом для любого приложения типа OLTP.

Я согласен, что ограничения памяти имели прямую связь с нормализацией ...

Ограничения памяти все еще имеют значение. Количество не проблема, скорость есть.

• Процессоры не работают быстрее в настоящее время (мы получаем больше ядер, а не циклов в секунду)
• Современные архитектуры ЦП пытаются преодолеть ограничение скорости, предоставляя отдельную память для каждого процессора ( NUMA ).
• Размеры встроенного кэша не увеличиваются со скоростью, сопоставимой с основной памятью.
• Пропускная способность памяти не так высока, как большинство людей ожидают. QPI находится в районе 25 ГБ / с.

Некоторые из этих основ были рассмотрены в разделе Когда использовать TINYINT поверх INT? который вы можете найти полезным. Я также рекомендовал бы следить за проделками @ThomasKejser ( блог ) от команды SQLCAT, поскольку они, как правило, находятся на острие повышения производительности базы данных. Недавние публикации о влиянии кэшей ЦП и шаблонов доступа к памяти и презентации SQLBits по реляционному моделированию для экстремальных масштабов DW являются хорошими примерами.

По моему мнению, речь идет о балансе между нормализацией и де-нормализацией . Я полностью согласен с тем, что платформы ORM - это просто подходы к достижению цели, но я не думаю, что именно эти структуры вызывают тенденцию к нормализации .

это все еще те дебаты, вы хотите эффективность времени или эффективность пространства. На момент появления теории реляционных баз данных дисковое хранилище стоит дорого, люди, очевидно, не хотят тратить на это столько денег, поэтому в это время реляционные базы данных - это те, кто твердо стоит на месте.

В наши дни все совсем по-другому, хранение очень дешево. Очевидно, что мы можем допустить большую избыточность по сравнению со старыми днями, это также ПОЧЕМУ появился подход BIG_TABLE. чтобы добиться большей эффективности времени, нужно жертвовать эффективностью пространства.

Но подход «больших таблиц» - это еще не конец истории, это все еще баланс между временем и пространством, с точки зрения управления объемными данными PB, некоторые разработчики также начали искать баланс обратно к эффективности использования пространства, поэтому Работы сделаны для нормализации некоторых данных в BIG-TABLE-подобных структурах.

Одним словом, подход к нормализации определенно не умер, но по сравнению со старыми временами он определенно упускается из виду.

CJ Date отвечает на ваш вопрос здесь - нормализационное (предварительное) видео бесплатно.

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

Короткий ответ: нормализация - это математически правильный способ ведения дел. Если вы не нормализуетесь должным образом, ваша модель данных просто неверна.