Что-то есть подозрение, что идет декартово произведение всех таблиц.

Запрос в студию!


Posted via ActualForum NNTP Server 1.4

Ой мля... Какой запрос страшный.

Беглым взглядом на скриншот могу сообщить следующее:

Есть завязка таблиц (назовем их для простоты aa, bb и, как это не странно,
bb) между aa и bb.

Но какая то странная завязка (как только интерпритатор не ругается?)

те. запрос вида

select ... from aa, bb, bb where aa.поле1= bb.поле2 or bb=12

Разберем:
Во первых, две таблицы с одинаковым именем (bb). Какую таблицу из них
интерпритатор должен рассматривать как bb в директиве where?
Не знаешь? Вот и он не знает. Поэтому он использует АЛИАСЫ (т.е. новые
именования этих таблиц (bb)) внутри запроса. Т.е. для интерпритатора
получается следующая контсрукция:

select ... from aa_1, bb_1, bb_2 where aa_1.поле1= bb.поле2 or bb.поле3=12

Обрати внимание, что интерпритатор не переименует таблицу bb в директиве
where, т.к. он не знает какую из них переименовать в bb_1, а какую в bb_2.
Таким образом получаем полную чухню в условиях ограничения выборки. Это раз.

Второе, cтоит OR. Это значит, что для всех записей таблицы bb, где поле3=12
выдернутся все варианты пересечения ВСЕХ (что самое ужасное) строк из всех
таблиц (т.е. тупо декартово произведение трех таблиц). Впрчем где выполнится
условие aa_1.поле1= bb.поле2 мы тоже получим большой набор ненужных строк,
т.к. bb - таблица не участвующая в запросе и поле2 - внутри запроса
константа.

Ну и резюмируя все выше сказаное если указатель записи в таблице bb (т.е.
той, алиас которой в данный момент называется bb) стоит на той записи, где
поле3=12 то в результирующем запросе получим количество записей равное
reccount('aa')*reccount('bb')*reccount('bb')

,т.е. при размере таблиц >= 12 мегабайт у нас наврятли ватит памяти даже на
серваке :)


Подведем общее итого. Проще вникнуть в задачу и написать ПРАВИЛЬНЫЙ запрос,
чем пытаться исправить данную ахинею.

PS А это ничто иное, как АХИНЕЯ, причем полная!


Posted via ActualForum NNTP Server 1.4

> Автор: Dima T
> Galyamov Rinat
> Ой мля... Какой запрос страшный.
>
> Это наследие FPD.

Да страшный он не в именовании полей/таблиц/стиле, а в полной безграмотности
и непонимании.
ОСНОВНЫЕ МОМЕНТЫ Я ОПИСАЛ


Posted via ActualForum NNTP Server 1.4

> select ... from a, b, c where a.f1 = b.f2 and b.f3 = c.f4 and ... and (
> ... and ... or ...)заменить на нормальный
>
> select ... from a inner join b on a.f1 = b.f2 inner join c on b.f3 = c.f4
> where ... and ( ... and ... or ...)
> Еще бы порядок JOINов немного поменять, но это только с текстом
> запроса можно показать.


Специально пересмотрел запрос.
Ну нету там вот этого:
where a.f1 = b.f2 and b.f3 = c.f4

И скобок (... or ...) нету. Есть просто ... and ...and ... and...OR ...


Posted via ActualForum NNTP Server 1.4

--



С уважением, Галямов Ринат Сагирович,
заместитель начальника отдела по автоматизации производства
отдела информационных технологий МУП "Томский энергокомплекс"
тел. (8-382-2) 26-30-72

"Dima T" <nospam@sql.ru>; сообщил/сообщила в новостях следующее:
news:6624533@sql.ru...
> Автор: Dima T
> Galyamov Rinat
> Специально пересмотрел запрос.
> Ну нету там вот этого:
> where a.f1 = b.f2 and b.f3 = c.f4
>
> И скобок (... or ...) нету. Есть просто ... and ...and ...
> and...OR ...
>
>
> Как нет? Еще раз смотри. После третьего AND открывается скобка и
> закрывается перед INTO.
> OR внутри скобок.

Разглядел :)

Но from a,b,b все равно полный гон :)

Надоть from a aa, b bb_1, b bb_2.

Ну ладно. автора в студию, а там посмотрим что с ним делать (это я про
запрос :) )


Posted via ActualForum NNTP Server 1.4