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

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

zbl писал(а):

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

Мне бы Ваши проблемы. А точнее, мне бы Ваш метод решения проблем.

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

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

~~~

Я хочу кинуть пару песчинок в тех, кто говорит, что изменение объёма данных при нормализации не существенно. Еще как существенно. В отличии от оперативной памяти для БД операция доступа к данным на диске не просто дорога, а очень дорога. Мы в большинстве своем склонны забывать, что скорость процессора за последние 20 лет выросла (условно) с 20 МГц до 4 ГГц, а скорость поиска данных на диске — с 30 мс до 5 мс. Аж в 6 раз. Поэтому любое обращение к диску — удар по производительности системы. Но чем больше данных, тем больше обращений — это закон природы…

[Yuri Gendelman]

2 Фома:
Обратите внимание на книгу:
Developing Time-Oriented Database Applications in SQL
by Richard T. Snodgrass
Morgan Kaufmann Publishers. 1999
Книга на dbebooks

Цитата:

Whether you're a database designer, programmer, analyst, or manager, you've probably encountered some of the challenges -- and experienced some of the frustrations -- associated with time-varying data. Where do you turn to fix the problem and see that it doesn't happen again? In Developing Time-Oriented Database Applications in SQL, a leading SQL researcher teaches you effective techniques for designing and building database applications that must integrate past and current data.

[Фома]

Yuri Gendelman писал(а):

2 Фома:
Обратите внимание на книгу:
Developing Time-Oriented Database Applications in SQL
by Richard T. Snodgrass
Morgan Kaufmann Publishers. 1999
Книга на dbebooks

Цитата:

Whether you're a database designer, programmer, analyst, or manager, you've probably encountered some of the challenges -- and experienced some of the frustrations -- associated with time-varying data. Where do you turn to fix the problem and see that it doesn't happen again? In Developing Time-Oriented Database Applications in SQL, a leading SQL researcher teaches you effective techniques for designing and building database applications that must integrate past and current data.

Большое спасибо за ссылочку. Я эту книжку там проглядел. Всегда хотел что-либо почитать на эту тему.

[zbl]

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

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

Ну, я ж не говорил, что это рецепт на все случаи жизни...
Да и в случае обновления данных он особо не поможет.
Мне кажется Фома не ждал в ответ на свой вопрос хрестоматийного "думайте сами, решайте сами".
Ясно, что в каждой конкретной ситуации нужно действоать сообразно.
Вопрос, как относиться к нормализации: как к полезному приёму, или как к догме?
Я думаю, что проблема нормализация-производительность похожа на проблему оптимизации в любом ПО.
А там есть очень даже аксиоматичный рецепт: начинай задумыватся об оптимизации только, если ты уже имеешь факт непотребо низкой производительности, но до того момента разрабытывай систему, не думая совсем об оптимизации (думай обо всём ином, кроме оптимизации).
Наверное, с нормализацией нужно поступать так же: сначала на автомате плодим тучу нормализованных таблиц, а уже только тогда, когда доказано, что эта туча слишком неповоротлива, начинаем понемногу ослаблять нормализацию, пытаясь добиться нужной производительности.

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

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

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

[PAV]

zbl писал(а):

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

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

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

zbl писал(а):

Та же проблема и с обычной файловой системой (которая и есть иерархическая база данных).
Как она решается? -- кешированием данных в оперативной памяти.

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

Кстати о птичках и других полезных насекомых: 1) кэш надо наполнять => (больше данных — больше запросов к диску — дольше наполнение кэша). 2) Кэш не безразмерен => (больше данных — больше вероятность нехватки кэша — больше вероятность дискового доступа).

[zbl]

PAV писал(а):

Если совсем не думать об оптимизации системы, то позже затраты на оптимизацию могут оказаться сопоставимыми с затратами на разработку, если не хуже.

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

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

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

zbl писал(а):

Как она решается? -- кешированием данных в оперативной памяти.

Ни хрена она не решается.

Совсем не решается? типа, если я 100 раз прочитаю один и тот же файл, то каждый раз время чтения будет одним и тем же (большим)?
Конечно, было бы куда лучше, если бы диск работал так же быстро, как память...

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

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

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

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

1) кэш надо наполнять => (больше данных — больше запросов к диску — дольше наполнение кэша). 2) Кэш не безразмерен => (больше данных — больше вероятность нехватки кэша — больше вероятность дискового доступа).

С этим мало кто станет спорить...
Если у нас терабайтная база, то на персоналке из магазина за углом мы её вряд ли потянем...
Ещё можно добавить: чем больше кеш, тем медленнее он работает...

[Фома]

To zbl.

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

[zbl]

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

Вопросы кеширования относятся к компетенции разработчика СУБД, а не разработчика конкретной БД. А вопросы нормализации бд лежат как раз в сфере прикладника.

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

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

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

zbl писал(а):

Совсем не решается? типа, если я 100 раз прочитаю один и тот же файл, то каждый раз время чтения будет одним и тем же (большим)?

Один из моих последних проектов был связан с торговлей на бирже. Протокол торгов — порядка 3 ГБ за день, в довольно компактной форме. Знаете, кэш не очень помогал.

zbl писал(а):

Почему больше данных на диске у Вас автоматически означает больше данных считывается с диска?

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

zbl писал(а):

он должен обеспечить максимальную переносимость БД

В очень многих проектах (особенно критичных к производительности БД) требование переносимости не стоит. Лично я его не видел ни разу.

Это не значит, что такие проекты не существуют. Существуют. При этом культурные разработчики немедленно делают уровень абстракции БД в программе, который выписывается в 2-3 вариантах под конкретные СУБД.

Перенос системы масштаба банка с Oracle на SQLServer — это проект, на который отводятся человеко-годы, причем в команду включают опытных администраторов БД, знающих обе системы. SQL стандартизован лишь на бумаге, реально я не знаю двух СУБД без серьезных практических отличий.

И опять: это не исключает возможности построения переносимых небольших систем, вроде БД домашней библиотеки. Но там на чем не делай — всё хорошо.

~~~

zbl, если Вы хотите что-либо серьезно и доказательно обсудить, давайте разбирать конкретный пример БД, ее работы, планы исполнения запросов, объемы данных и т.п. «Теория суха, мой друг, // А древо жизни вечно зеленеет.» А БД — это очень практическая дисциплина.