Нормализация БД - догма?

[Фома]

Вот я постоянно спорю сам с собой. А всегда ли оправданно я нарушаю эти заповеди? Ну очень иногда бывает нужна скорость. Я конечно понимаю, что если следовать заветам Бойса-Кодда и прочих мэтров, то я получу выигрыш в объеме, целостности и т.п. Но почему-то почти никто из этих метров не задумывался о вопросах производительности. Так вот собственно и вопрос: А Вы чего думаете

Добавлено спустя 14 минут 47 секунд:

В догонку. Я постоянно воюю с любителями интеллектуальных атрибутов. На мой взгляд, единственное оправдание их поддержки - наличие offline юзеров. А у вас как

[Yuri Gendelman]

Фома писал(а):

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

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

[zbl]

Фома писал(а):

Вот я постоянно спорю сам с собой. А всегда ли оправданно я нарушаю эти заповеди?

Помоему, во всех умных книгах прописано: "с нормализацией легко можно береборщить; не используйте её механически".
Есть хороший универсальный рецепт: не применяй какой-то приём или технологию просто потому, что она "хорошая"; обязательно сформулируй самому себе, что конкретно (а не абстрактно, вроде "лучше целостность") даст в данной конкретной задаче применение данной технологии по сравнению с другими приёмами, которые ты умеешь здесь применить.

Фома писал(а):

Ну очень иногда бывает нужна скорость.

А можно простенький примерчик на то, как проигрыш в нормализации даёт выигрышь в скорости?

[незваный гость]

zbl писал(а):

А можно простенький примерчик на то, как проигрыш в нормализации даёт выигрышь в скорости?

С нашенским удовольствием. Пример искусственный, но отражает существо происходящего.

Есть БД книг. Запись из двух элементов, название и цвет обложки (RGB, три целых). Ключевое требование — поиск только по названию.

Нормализация требует сделать отдельную таблицу цветов. Реально, при поиске только по названию, это приведет к дополнительным дисковым запросам.

Формально, вроде цвет не является объектом, но это не так: у него есть Pantone, может быть информация о виде краски, и т.п. Т.е., при развитии системы такая таблица может и появиться. Возможен и компромисс: часть информации будет дублироваться в основной таблице, а часть — нормализована.

[OZH]

Понятие денормализация уже давно существует и никого не смущает.

[Фома]

zbl писал(а):

А можно простенький примерчик на то, как проигрыш в нормализации даёт выигрышь в скорости?

Вот пример из жизни. БД, связанная с учетом (бухгалтерским, складским и т.п.) , теоретически может хранить только проводки движения денег, товаров, ... Но при этом будет очень долго на больших объемах информации отвечать на вопрос: А каковы были остатки на счетах, складах... на 25 июля позапрошлого года? Альтернатива - хранить историю остатков, а это противоречит теории нормализации, но сильно убыстряет процесс!

[Yuri Gendelman]

Фома писал(а):

... теоретически может хранить только проводки движения денег, товаров, ... Но при этом будет очень долго ... отвечать на вопрос: А каковы были остатки на счетах, складах... на 25 июля позапрошлого года? Альтернатива - хранить историю остатков, а это противоречит теории нормализации, но сильно убыстряет процесс!

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

[незваный гость]

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

Разумеется, это не всегда приемлемо. Но этот подход — еще один вариант баланса быстродействия и корректности.

[Stanislav Budarin]

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

[Фома]

Yuri Gendelman писал(а):

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

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

[zbl]

незваный гость писал(а):

Есть БД книг. Запись из двух элементов, название и цвет обложки (RGB, три целых). Ключевое требование — поиск только по названию.

Нормализация требует сделать отдельную таблицу цветов. Реально, при поиске только по названию, это приведет к дополнительным дисковым запросам.

Фома писал(а):

Вот пример из жизни. БД, связанная с учетом (бухгалтерским, складским и т.п.) , теоретически может хранить только проводки движения денег, товаров, ... Но при этом будет очень долго на больших объемах информации отвечать на вопрос: А каковы были остатки на счетах, складах... на 25 июля позапрошлого года? Альтернатива - хранить историю остатков, а это противоречит теории нормализации, но сильно убыстряет процесс!

Мне ожидалось, что пример будет о добавлении данных в базу, а не о извлечении данных...
В тех же умных книжках понаписано, что таблица -- это логическая, а не физическая структура, мол СУБД хранит данные совсем не в виде таблиц, и поэтому быстрота поиска не определяется тем, по скольким таблицам тот идёт, а больше тем, как хороша реализация (кеширование, индексация и т. п.).
Выходит, то проблема СУБД, а не разработчика БД (ессно, тот должен учитывать особенности используемых им СУБД).
На это у меня всегда возникало недоумение: но при добавлении-то данных к базе всяко имеет значение в одну таблицу мы добавляем или в несколько.
Например, ввод данных о новой книге требует обновления двух таблиц -- это всяко медленнее, чем обновление одной; или я как раз и не прав?

Строго говоря, думается, любая структуризация базы (когда используется не одна-единственная таблица) будет снижать производительность как запросов, так и обновлений.
То есть, полюбому речь идёт о том, чтобы найти разумный баланс противоречивых желаний.
Вывод: присоединяюсь к высказанному уже мнению о том, что нормализация не догма, но типа бестпрактис, на который нужно ориентироваться, но не применять механически где не попадя.

Добавлено спустя 11 минут 13 секунд:

незваный гость писал(а):

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

И у меня снова вопросик из любопытсва...
Например, я имею очень большую кучу нормализованных таблиц, которую я в основном читаю в основном даже похожими запросами.
Чтобы не париться, я делаю представление, которое будет, собственно, как раз той ненормализованной таблицей, которую я бы использовал, если бы букварей не читал.
Вопрос: способна ли едрёна СУБД устроить так, чтобы запрос к представлению работал хоть б чуть быстрее, чем аналогичный запрос к туче нормализованных таблиц?

[Фома]

zbl писал(а):

поэтому быстрота поиска не определяется тем, по скольким таблицам тот идёт, а больше тем, как хороша реализация (кеширование, индексация и т. п.).
Выходит, то проблема СУБД, а не разработчика БД (ессно, тот должен учитывать особенности используемых им СУБД).

Быстрота поиска, прежде всего, определяется именно структурой БД, а следовательно разработчиком.

zbl писал(а):

Строго говоря, думается, любая структуризация базы (когда используется не одна-единственная таблица) будет снижать производительность как запросов, так и обновлений.

Это совсем неверно. Читайте классиков. Например, все известные мне попытки организации атрибутного хранения данных, при реализации ОО БД, закончились провалом именно по причине низкого быстродействия.

zbl писал(а):

Вопрос: способна ли едрёна СУБД устроить так, чтобы запрос к представлению работал хоть б чуть быстрее, чем аналогичный запрос к туче нормализованных таблиц?

Ну тут я вообще ничего не понял.

[zbl]

Фома писал(а):

zbl писал(а):

поэтому быстрота поиска не определяется тем, по скольким таблицам тот идёт, а больше тем, как хороша реализация (кеширование, индексация и т. п.).
Выходит, то проблема СУБД, а не разработчика БД (ессно, тот должен учитывать особенности используемых им СУБД).

Быстрота поиска, прежде всего, определяется именно структурой БД, а следовательно разработчиком.

Ну, и представим теперь себе чудо-СУБД, которая все данные упрямо хранит в одной-единственной хеш-таблице (структуре данных), независимо от того, сколько таблиц создал разнаботчик БД с помощью create table.
Естественно, она же сама должна и расплетать все появляющиеся от такой глупой реализации проблемы...
Вопрос: как в данном случае структура БД, которую придумал разработчик, влияет на производительность запросов?

Фома писал(а):

zbl писал(а):

Строго говоря, думается, любая структуризация базы (когда используется не одна-единственная таблица) будет снижать производительность как запросов, так и обновлений.

Это совсем неверно. Читайте классиков.

Я имел в виду, что практически всегда, когда разработчик создаёт несколько таблиц вместо одной большой-пребольшой таблицы (даже, наверное, не в 1NF) запросы и тем паче обновления будут выполняться медленнее.
Так и нормализация автоматически снижает производительность.
Вопрос в том, как найти правильный баланс производительность/иные_прелести.

Фома писал(а):

zbl писал(а):

Вопрос: способна ли едрёна СУБД устроить так, чтобы запрос к представлению работал хоть б чуть быстрее, чем аналогичный запрос к туче нормализованных таблиц?

Ну тут я вообще ничего не понял.

Имеется представление (view), которое служит интерфейсом к нескольким таблицам.
Используют ли СУБД какие-нибудь технологии (вроде кеширования), которые позволяют быстрее выполнять запрос к представлению, чем соответствующий ему запрос к нескольким таблицам?

[Фома]

zbl писал(а):

Ну, и представим теперь себе чудо-СУБД, которая все данные упрямо хранит в одной-единственной хеш-таблице (структуре данных), независимо от того, сколько таблиц создал разнаботчик БД с помощью create table.
Естественно, она же сама должна и расплетать все появляющиеся от такой глупой реализации проблемы...
Вопрос: как в данном случае структура БД, которую придумал разработчик, влияет на производительность запросов?

Так она и не сможет без грамотно разработанной разработчиком структуры данных быстро работать с такой "чудо" хеш-таблицей.

zbl писал(а):

Я имел в виду, что практически всегда, когда разработчик создаёт несколько таблиц вместо одной большой-пребольшой таблицы (даже, наверное, не в 1NF) запросы и тем паче обновления будут выполняться медленнее.
Так и нормализация автоматически снижает производительность.
Вопрос в том, как найти правильный баланс производительность/иные_прелести.

При увеличении длины записи таблицы будет расти время работы с ней, т.к. вы вынуждены будете таскать запись размером, например, несколько мегабайт, только для того чтобы установить значение одного единственного поля типа bool.

zbl писал(а):

Имеется представление (view), которое служит интерфейсом к нескольким таблицам.
Используют ли СУБД какие-нибудь технологии (вроде кеширования), которые позволяют быстрее выполнять запрос к представлению, чем соответствующий ему запрос к нескольким таблицам?

Конечно используют, причем в независимости от того к какому количеству таблиц идет запрос.

[zbl]

Фома писал(а):

Так она и не сможет без грамотно разработанной разработчиком структуры данных быстро работать с такой "чудо" хеш-таблицей.

Структура данных, разработанная разработчиком безвозвратно похоронена чудо-хеш-таблицей, и от той структуры скорость запросов больше вообще не зависит.
Есть зависимость только от количества данных, которые будут извлечены и, разумеется от чудо-алгритма работы с чудо-хеш-таблицей.
Но вот то, какие именно данные будут содержаться в базе -- это, конечно, влияет на всё на свете и на скорость запросов тоже.
Я имею ввиду только распределение столбцов (атрибутов) по таблицам и зависимость только от этого распределения.
СУБД хранит данные не в виде таблиц и скорость выполнения запросов не зависит (должна бы совсем не зависеть... можно мечтать об этом...) от того, одна ли ненормализованная таблица используется или тьма нормализованных.
Если не так, то это проблема СУБД, а не разработчика БД: тот вообще по возможности не должен завязываться на особенности конкретной реализации.

Фома писал(а):

При увеличении длины записи таблицы будет расти время работы с ней, т.к. вы вынуждены будете таскать запись размером, например, несколько мегабайт, только для того чтобы установить значение одного единственного поля типа bool.

Но ведь я ж указал в select, что мне нужно только значение одного поля, а не вся запись.
Не моя проблема, чтобы СУБД хранила таблицы так, чтобы поиск по ключу всегда занимал лагорифмически мало времени, а с диска читались только те данные, что я просил (плюс упереждающее чтение, кеширование, ИИ...).
С обновлением данных уже, правда, эти аргументы не так легко проходят...

Фома писал(а):

zbl писал(а):

Имеется представление (view), которое служит интерфейсом к нескольким таблицам.
Используют ли СУБД какие-нибудь технологии (вроде кеширования), которые позволяют быстрее выполнять запрос к представлению, чем соответствующий ему запрос к нескольким таблицам?

Конечно используют, причем в независимости от того к какому количеству таблиц идет запрос.

Отсюда рецепт: если паримся с тьмой нормализованных таблиц, создаём для них такое представление, чтобы имитировало ту ненормализованную таблицу, что мы бы использовали, не читав букварей.
А уж максимальное повышение производительности тогда будет проблемой СУБД: мы ж и букварные истины соблюли (таблицы нормализовали) и максимальную информацию о наиболее частых запросах до СУБД донесли (в виде представления).
Так сказать, сделали всё, что от нас зависело...