|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Serg Vasiltsoff 2:5020/400 04 Apr 2001 15:29:07
To : All
Subject : Re: Дремина хитрость 2
--------------------------------------------------------------------------------
> Hет, не закрыт, я говорю про быстродействие а вы говорите про размер.
Это более, чем сильно связанные вещи. Hеприлично говорить о быстродействии
системы, если она хранит 5 записей.
> Мой денормализованный вариант нужен _только_ для отображения клиенту,
Бред. Денормализацию не применяют "_только_ (!!!) для отображения"
> Причины по которым я так сделал идентичны тем причинам почему в MSSQL2000
> были введены индексы по вычисляемым полям и на view, понимаете?
В 2К просто материализовали представления. Вы хоть цену представляете,
которую придется заплатить базе за такую материализацию?! Это же хороший шаг
к OLAP! Модификация таких объектов выльется в хорошие косты!
> Просто я не могу смотреть когда выводится продукция на экран клиента
> и к ней _каждый_ раз прилепляется еще куча вспомогательных таблиц,
> в то время когда информация в этих дополнительных таблицах изменяется
> _очень_ редко... зачем ее каждый раз просчитывать?
Бред. Hикто ничего не пересчитывает. _Подчитывает_ - да, но об этом у Вас ни
одного слова.
> Я так и делаю, и большие динамические таблицы полностью нормализованы...
> Вопрос в том, где эта граница... Она зависит от задачи, от ПО, от
железа...
> боюсь что я еще не достиг ее в своей задаче... Я просто использую этот
> метод где он себя оправдывает, если при определенных условиях он
> перестанет работать, то я от него откажусь.
Тогда не надо объяснять денормализацию удобствами отображения данных на
клиенте. Вот ограничениями сервера, железа, задачи, ... она объясняется
очень просто и понятно, отображением - нет.
--- ifmail v.2.15dev5
* Origin: Lime Systems (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
