|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Serg Vasiltsoff 2:5020/400 04 Apr 2001 15:29:08
To : All
Subject : Re: Дремина хитрость 2
--------------------------------------------------------------------------------
> >Hет, это Вы, Уважаемый, сделайте таблицу с 10,000,000 строк в своем и
> >нормализованном варианте. Сделали? Hе получается? Hе работает? Индексы
> >девать некуда? Вопрос закрыт?
>
> Поясни пожалуйста. Даже я не понял. Ты имеешь в виду, что данные больше
> объема
> будут занимать ?
Для денормализованной таблицы придется тащить в каждой строке привнесенные в
нее справочные значения. Это, как ни странно, требует места и немало. Как
правило на денормализацию идут с 50% (как минимум) ростом строки в таблице,
что проводит к примерно удвоению места под данные. Hо это - еще не все! По
этим денормализованным полям нуджны индексы, иначе работать с ними будет
невозможно, если раньше в эти индексы входили только ФК, то теперь
(денормализация!) - native - значения, а это - опятьрост занимаемого места,
да немалый!
> >Для таблицы с потенциально ограниченным набором данных ( и не растущим! )
> >типа справочник валют или справочник банков можно делать сколь угодно
> >широкие поля в угоду прикладной задаче. А вот в постоянно растущих -
только
> >жесточайшая нормализация (как меня сейчас свои же и побъют ;))
> Опять не понял.
Если у меня есть справочник, то есть набор данных, который даже теоретически
не может превысить определенный порог (справочник валют вряд ли разрастется
свыше 1000 позиций - кодировку менять придется ;)) - то его можно делать
сколько угодно "широким". А вот если рост данных для таблицы / объекта
предсказать нельзя, более того, данных туда постоянно прибавляется, то любой
ценой надо выделить и вынести за пределы таблицы все, что можно, оставив
храниться гольную сущность и ФК. Это к тому, что есть обязательная граница
между нормализацией / денормализацией. Безумие сильно денормализовывать
постоянно растущие данные, но "конченый" справочник на 100 полей нет смысла
дробить на десяток таблиц только из-за того, что прикладную задачу "ставил"
безумец.
--- ifmail v.2.15dev5
* Origin: Lime Systems (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
