Трава у домаХочется узнать - как влиеят наличие представления на производительность базы (Sybase 12.5.3)


Если говорить в двух словах, само наличие или отсутствие VIEW никак не влияет на производительнось. Но это не значит, что наличие VIEW в запросе не
может сделать этот запрос катострофически медленно выполняемым. Все зависит от того, какой VIEW используется.

Дело в том, что VIEW оптимизируется вместе со всем запросом, сначала как бы подставляется в запрос, а потом весь запрос оптимизируестя. Но при этом сервер должен сохранить логическую эквивалентность view внутри запроса и сложные view могут приводит к реализации т.н. стратегии материализации view, и обычно это хорошо (для скорости работы запроса) не кончается.
Приведу пример :

В таком случае скорее всего сервер сначала выберет всю таблицу my_table, группируя ее по соотв. полям, а потом применит фильтр по s_f3 и f2.

Трава у дома
Суть в том, что есть очень большая таблица - и очень интенсивно обновляемая, одно из полей у нее datetime.
Хочется иметь представление, где это поле datetime включает записи, созданные например в прошлом месяце. То есть скажем я это поле с каким-нибудь datepart(mm,dateadd(mm,-1,getdate())). Ну и еще во вьюхе с некоторыми полями операции произведу.

Насколько это будет накладно для сервера?

Такое view скорее всего будет так же оптимизируемо, как и просто запрос.
Т.е. view на производительность не повлияет
Однако надо заметить, что применение выражений типа datepart(mm,dateadd(mm,-1,getdate())) плохо сказывается на производительности (как просто запроса, так и запроса с view). Потому что по такому выражению применить индекс сервер не сможет. Рекомендую попробовать выражения LIKE с датой (которые очень хорошо оптимизируются), хотя не представляю как это можно
применить для данного конкретного случая.

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

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

Думал - что если от этого уйти, использовав вьюху, но видимо это будет гораздо тормознутее.

Нет, не будет. В таком случае вы можете просто во VIEW всобачивать две константы границы месяца в BETWEEN. Или LIKE.
Это будет эффективно.

create view MYTABLE_last_month
as
select *
from MYTABLE
where date between '20060201' and '20060228'

Но учтите, что поскольку эффективно выборка из этого VIEW будет отличаться от выборки из самой таблицы добавлением в ваш запрос условия
and date between '20060201' and '20060228'
, а записей во всей таблице, как я понимаю, гораздо больше, чем за месяц,
то ваши запросы могут выполняться с меньшей скоростью. Но view здесь ни при чем. Просто если запрос не возмет индекс по date, то он будет обрабатывать записи не за месяц, а все.

вообще в вумных книжках написано, что бывают материализованные представления, когда результаты запроса постоянно хранятся в базе.
Но бывает ли такое в ASE?

Не бывает пока.

_makSim
where date between dateadd(dd,1-datepart(dd,getdate()),getdate())
and dateadd(dd,-datepart(dd,getdate()),dateadd(mm,1,getdate()))

Зачем пересоздавать? Вот такой запрос по-моему не запретит использование индекса по date.



Не запретит конечно, но индекс использоваться скорее всего не будет.
Потому что SARG-ом стоит выражение. Оптимизатор не способен вычислить выражение и оценить его селективность. Поэтому индекс по date может использоваться в запросе, но не для оптимизации SARG-а, а если его выберут еще по каким-то критериям.

А хинт индекса во VIEW поставить нельзя (т.е поставить-то можно, да работать не будет).

работаю с 7й и 9й

Ну начнем с того, что разговор об ASE, а не ASA.

с ростом таблиц вьюс начинает работать всё медленнее и медленнее... оно и понятно...

Это запросы работают у вас все медленнее и медленнее. Потому что плохие они у вас, таблицы сканируют. Хорошие запросы ведут себя как логарифм от размера таблицы, т.е. практически не растут. А VIEW здесь ни при чем.

rashmanя не понимаю термина "плохой запрос" и "хороший запрос". если мне надо сделать выборку всех номеров накладных из двух таблиц, то без сканирвоания целой таблицы здесь не обойтись.


Это и есть плохой запрос. т.е. он может быть нужный, но плохой.

rashman
мой опыт пока показал, что обработка во временных таблицах происходит быстрее.


Как бы вам сказать, а то вы опять обидитесь еще ...
Это неправильно. Нельзя сказать, что временные таблицы работают ВСЕГДА быстрее. Когда-то быстрее, когда-то - наоборот. Обычно с ними быстрее, когда у вас есть сложная выборка (возможно со сканированием таблицы), которую потом нужно несколько раз обрабатывать. Таким образом, выделяя данные во временную таблицу, мы делаем сложную выборку только один раз, а потом с маленьким числом записей уже все быстро работает.

Но иногда само наличие временной таблицы будет наоборот портить производительность -- вр. таблицу надо наполнить, и потом удалять, это тоже IO и время.