"Boltik Evgeny" ...
>
> >> когда можно было сделать что то списка
> >> страниц со ссылками на старые записи и пробежав только по этим страницам
> >> в
> >
> > Ну и будет у тебя список со всей базой - и шо ?
>
> С чего это со всей базой. Старые периоды ни кто не правит практически.
> Правится и изменяется только новая информация.
Так может возьмём твою бд за образец для всех остальных ? Для биллингов,
crm'ов, etc ?
> >> базе меняется не вся информация а только малая часть ее.
> >
> > Та ты шо ?! Т.е. берём твои БД за образец и тюним движок под них ?
> > Ты уж как-нибудь сам...
>
> Причем здесь мои базы. У одного клиента вылезли тормоза и ты думаешь теперь
> что у всех и только на моей базе. Нук раскажи нафига править данные
> складского учета или бух-го за 2004 год? И что будет правится весь 2004 год?
Женя, если ты не видишь ничего дальше собственного бухучёта, то не нада
рассказывать за других, да ?
> Суть была не в транзакциях а в принципе не разростания файла базы данных
> т.к. удалялось и добавлялось много записей.
Нафига тогда тут это рассказывать ? Я же не описываю тут все свои
курсовые...
> >> Получается что -housekeeping 100 приведет к еще большим тормозам, а я так
> >> надеялся что наоборот :(.
> >
> > С какой стати ты на это надеялся ?
>
> Документацию не читал т.к. была на не русском.
Вот молодец, так и надо
> > PS Я уже просил _сначала_ думать, а _потом_ писать
>
> А кто сказал что я не думаю? Я высказал то что я делал для ускорения и
> уменьшения файла. И что теперь молчать и не предлагать вообще что ли.
> Получается вообще ничего не предлагать. Я и так практически только читаю
> конфу.
Если имеешь что предложить, то нужно быть готовым отстаивать своё
предложение. И делать его в человеческом виде, а не как поток сознания,
пролившийся ниже
> На держи фантазию
Ты это уже описывал с год назад. За это время ты не смог даже вразумительно
сформулировать свою фантазию - либо оно тебе не надо, либо тебе пофигу
понимает ли тебя кто-нить ещё, либо и то, и то
> Я постоянно впарываюсь, да скорей всего и не я один в ситуации когда данные
> можно было найти быстро а они ищутся долго. Происходит много лишних чтений.
а нефиг вводить столько данных ;)
> Дак вот есть мысля как улучшить этот механизм. Сейчас нужно точное
> совпадение написания того что в computed by написано.
>
> И так есть 2 таблицы
>
> T1
> F1
> F2
>
> T2
> F1
> F3
>
> есть вьюха
>
> V1
> F1, F2, F3
> from T1, T2
> where T1.F1 = T2.F1
>
> а теперь выполняем такой запрос
>
> select * from V1 where F2 = x and F3 = y
при чём тут computed by ?
> ну естественно оптимизатор в трансе придумал что ему вздумалось из таблицы
> T1 масса ненужных чтений
какой транс ? где реальные примеры с цифрами ?
> а вот теперь давай ему поможем и создадим индекс
> CREATE INDEX idx2 ON T2 (
> (select F2 from T1 where T1.F1 = T2.F1) [as F2],
> F3)
ты понимаешь что такое индекс ?
> а вот после этого индекса запрос будет летать
...низко-низко...
> а) теперь оптимизатор знает что поле F2 существует в индексе и должен думать
> что индекс как буд то выглядит так CREATE INDEX idx2 ON T2 (F2, F3) то есть
> мы обманываем оптимизатор поле в нем comp by но физически оно отсутствует
> ситуация просто супер не надо плодить избыточных данных
индекс - уже избыточные данные
> б) действия сервера он должен создать внутренний триггер у таблицы T1 на
> обновление на случай изменения F2
самому сложно создать ? и что этот триггер должен делать ?
> Сейчас приходится вводить доплнительное поле в T2 F2x и создавать индекс
> CREATE INDEX idx2 ON T2 (F2x, F3)
а в чём проблемы ? ещё и триггер создавать надо, к счастью, вполне
нормальный...
а если на одну запись t2 приходится 2 в t1 - шо тогда ? или в твоей образцовой
бд
такого не бывает, а на остальных нам, как обычно, начхать ?
> А все по той причине что если не создавать такую избыточность на один селект
> тратится более 1 секунды (это на моем P4 3Гц) а у клиентов PIII стоят. После
> создания избыточности получаем запрос на милисикунды. А при выполнении
> отчетов скорость выростает и мы экономим минуты клиентов и массу времени
> разработчиков.
прям массу ? а если её ещё на ускорение времени разработчиков умножить -
этож будет сила времени разработчиков !
> Вывод мы получим теже действия которые делает пользователь при обновлении
> данных, то есть на производительность при обновлении данных никак не
> повлияет т.к. обновление информыции одинакова не зависимо ни отчего. А вот
с какой стати ? триггер твой волшебный святой дух обновлять будет ?
> избыточность данных будет удалена из базы и улучшится производительность.
так ты материализованные представления хочешь, что ли ? (воскликнул я,
после двадцатого перечитывания этого опуса...) надо же так замаскировать...
Пока нет желающих это делать
--
Хорсун Влад
