> SELECT t1.otdel,SUM(icase(t1.zvanie='Доцент',1,0)) as
> sum_docent,SUM(icase(t1.zvanie='Профессор',1,0)) as sum_professor ;
> from (SELECT otdel,zvanie from sotrudniki WHERE zvanie
> in('Доцент','Профессор')) t1;
> GROUP BY t1.otdel


Чего-то не понял. А зачем в данном случае внутренний запрос??? Чем не
устраивает конструкция:

SELECT t1.otdel, SUM(icase(t1.zvanie='Доцент',1,0)) as sum_docent,
SUM(icase(t1.zvanie='Профессор',1,0)) as sum_professor ;
from sotrudniki t1;
WHERE zvanie in('Доцент','Профессор'));
GROUP BY t1.otdel


Posted via ActualForum NNTP Server 1.4

> Да согласен, внутренний запрос при выводе в строчку не нужен и
> предложение where тоже, т.к.
> icase()-обозначит за единицу только наименования указанные в
> нём(.t.), а остальные приравняет нулю
> (но если званий огромное количество то запрос с агрегированием может
> быть тяжёлым, гораздо легче выбирать из уже готового набора из двух
> должностей чем из 222 Хотя неизвестно как будет это делать фокс -возможно
> указанный запрос и будет самым легким) т.о.:

А вот и нет. Если есть индекс по полю zvanie, то запрос с директивой WHERE
отработает гораздо быстрее


Posted via ActualForum NNTP Server 1.4

> Хм ...
> Где написано, что фокс будеть хватать индекс с такой директивой?
Help и иже с ним!

> План выполнения разве в фоксе есть?

План есть, но не для простых смертных :)

sys(3054) позволяет оценить какие индексы подключились при выполнении
запроса.


Posted via ActualForum NNTP Server 1.4

> Вот спасибо!!! :-)

Ну и еще одна тонкость.

Если по полю field1 есть индекс без дериктивы for, то он будет подключен в
конструкции:

select ... from table1 where field1=eValue

Но не будет подключен в случае

select ... from table1 where eValue = field1

Т.е. название поля должно стоять СЛЕВА от знака сравнения, а значение с
которым идет сравнение поля, соответственно, СПРАВА

Чтобы запрос был оптимизируемым по индексам, индексное выражение должно
ПОЛНОСТЬЮ совпадать с тем, что стоит СЛЕВА от знака сравнения.
Например, если индекс построен по Alltrim(field2), значит в конструкции
where должно быть Alltrim(field2) == (=, >, <, IN (select ...) и т.д.)


Чтобы запрос был полностью оптимизируемым по индексам нужно в таблицы
добавить индекс по DELETED()


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

Например, если значение поля field3 в подавляющем большинстве = 3, то
наличие индекса по полю field3 в запросе вида:
select * from table1 where field3=3
приведет к замедлению выборки. Т.к. FOX сначала просмотрит индексы, потом
вытащит почти всю таблицу.

Без индексов он просто вытащит почти всю таблицу, что может оказаться
гораздо эффективнее (легче откинуть 5% записей от самой таблици после ее
полного скачивания, чем прокачивать по сети весь индекс для принятия решения
о том, какие записи необходимо скачать из таблици).

В реальных таблицах значения полей как правило разные (нет больших групп
(более 90% от общего кол-ва записей) с одинаковыми значениями), поэтому
наличие индексов приводит к реальной оптимизации запросов, а вот количество
удаленных записей как правило меньше чем 5% , поэтому наличие индекса по
deleted() в такой ситуации привете лишь к замедлению выборки, не смотря на
то, что sys(3054) заявит о полной оптимизации.

И еще, нужно иметь в виду, что наличие индексов приводит к замеделнию
операций вставки и изменения записей, т.к. при таких операциях есть
необходимость изменения индекса!

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


Posted via ActualForum NNTP Server 1.4

> А про индекс delete() не совсем понял, если их около 5 или менее
> процентов, то наличие индекса должно ускорить выборку (SQL)... или я
> что-то не так понял???

Суть вопроса в следующем. Если для доступа к данным можно использовать
индекс (т.е. имеется соответствующий индекс) - то фокс подхватит его в любом
случае. Исключением могут быть set opti off или выполнение команды с опцией
noopti (brow for ... noopti и т.д.).
Но при этом происходит отказ от всех индексов для данной команды.


Итак, выяснили, что фокс использует по возможности индексы.

Допустим есть индекс по deleted() и НЕТ удаленных записей в таблице.
ПРи этом set deleted ON (если off - то необходимость в индексе по deleted
отпадает и фок его не берет)


Тогда любая команда использующая оптимизацию рашмора (в том числе select *
from table 1 ) подключит индекс по deleted()
Т.е. на локальную машину будет вытащен соответствующий индекс, просмотрен,
принято решение о том, какие записи нужно вытянуть на локальную машину. А в
данном случае это все записи.

В случае, если индекаса по deleted() нет. Фокс просто прокачивает таблицу на
локаль, проверяет что удаленных нет и все.




Если удаленные записи есть, то с индексом - вытягиваем индекс,
просматриваем для НЕУДАЛЕННЫХ, вытягиваем соответсвтующие записи.

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

Так вот выборка данных с индексом будет тем эфективнее чем выборка без
индекса, чем более разнородные данные хранятся в полях, по которым строится
индексное выражение.


Если удаленных 5 записей, а всего записей в таблице 1 000 000 - то
естественно наличие индекса по deleted() только замедлит выборку.
Потому что гораздо быстрее просмотреть непосредственно таблицу отказаться от
пяти записей, чем целиком вытягивать индекс и в нем просматривать для
неудаленных.

А вот по первичному ключу наличие индека позволит МНОГОКРАТНО ускорить
выборку, т.к. каждое значение ключа уникально и для того чтобы вытянуть ОДНУ
запись гораздо эффективнее просмотреть индекс и найти одну запись, которую
необходимо вытянуть, чем просматривать всю таблицу в поисках нужной записи.


Этот ГРАНИЧНЫЙ процент "однородности", при котором происходит реальная
оптимизация при применении индекса сильно зависит от значений индексного
выражения и колеблется в районе 5 - 8 %%.



Иными словами, если ты заранее знаешь, что в твою выборку ГАРАНТИРОВАННО
попадет 95% всех записей из таблицы - то без индексов такой запрос
отработает быстрее чем с индексами.


PS Чего - то я разошелся :)


Posted via ActualForum NNTP Server 1.4

> Поясните, Вы говорите о фильтрованном индексе или же нет, если нет,
> то каков по Вашему размер индеса по deleted() для 5-ти записей для таблы в
> 1млн записей, из вышесказанного он получается размером с исходную таблицу

Я говорю про НЕФИЛЬТРОВАННЫЙ индекс.

Про фильтрованный вообще есть смысл говорить только в очень ограниченной
категории применения.

А нефильтрованный - он строится для КАЖДОЙ записи, неважно удалена она или
нет. Есть два значения .f. и .t. И то и другое - ЗНАЧЕНИЯ.

Поэтому при кол-ве записей = 1 млн. говорить о "размере индеса по deleted()
для 5-ти записей" несколько неправильно



По размерам индекс зачастую занимает меньший размер чем данные в таблице, а
вот про delete - не уверен (Даже скорее наоборот - больше, при чем в
несколько раз. Т.к. индекс - это ДВУНАПРАВЛЕННЫЙ массив и в индексном файле
хранится не только значение (скорее всего в обработанном виде) но и ссылка
как на предыдущий элемент массива, так и на следующий). Документации по
внутреннему устройству индексных файлов VFP не видел и даже не слышал, что
это где-то есть.


А то что поиск идет по индексам намного быстрее - так это не зависит от
размера индекса. Это зависит от его внутренней организации.


Posted via ActualForum NNTP Server 1.4

> из вышесказанного он получается размером с исходную таблицу

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

Так вот скачать ТОЛЬКО нужные столбцы и их проверить при малом количестве
ОТКИДЫВАЕМЫХ (не соответсвующих условиям выборки) записей по времени гораздо
эффективнее чем скачивать весь индекс (ТЭГ, а не весь индексный файл).


Posted via ActualForum NNTP Server 1.4