cherrex_Den пишет:
> В очередной раз наши программисты свояли запрс, на который сервер выдаёт:
> error
> The current query would generate a key size of 676 for a work table.
> This exceeds the maximum allowable limit of 600.

> Что делать?
переписывать запрос. Это от статистики не зависит совсем, зависит только от
запроса. Это случается, когда суммарный размер полей, указанных в GROUP BY
слишком большой или когда список вывода в запросах с DISTINCT или UNION без ALL
очень большой. Всегда почти можно переписать запрос, например, вынося JOIN-ы
с таблицами-атрибутами из такого запроса, чтобы выполнить эти операции
(GROUP BY, DISTINCT или UNION ), поместив результат во временную таблицу, а
потом уже с ней с JOIN-ить.

Если это -- GROUP BY - там есть ещё один рецепт, если нужно, могу отдельно
рассказать.
Posted via ActualForum NNTP Server 1.4

cherrex_Den пишет:

> да проблема в GROUP BY, там полей 20 указано! Допустим все эти 20 полей
> нужны в GROUP BY, что тогда делать?

В SQL пологается в GROUP BY писать все поля, которые не находятся под
агрегатами. В ASE это делать не обязательно. И хотя многие (и я в том
числе) считают, что это очень плохо, потому что это приводит к катастрофическим
ошибкам в запросах, в данном случае это может помочь. Сейчас попробую объяснить как.

Обычно в запросе с GROUP BY все поля делятся на три категории:
(1) поля, являющиеся идентификаторами сущностей, составляющих каждую группу
в группировке. Например, если мы получаем строки, соответствующие сотруднику и
его месту работы (ставке), то это будут идентификаторы сотрудника и ставки.

(2) поля, являющиеся неключевыми атрибутами сущностей, составляющих каждую
группу в группировке. Например, если мы получаем строки, соответствующие
сотруднику и его месту работы (ставке), то это будут ФИО сотрудника и название
ставки.

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

Группы (1) и (2) должны входить в GROUP BY. (1) обычно короткие, (2) обычно,
наоборот, длинные.

Можно переписать запрос так, чтобы он НЕ содержал поля группы (2).
Чтобы это сделать, но не сломать запрос, нужно переписать GROUP BY так, чтобы
он:

содержал все поля группы (1) (т.е. их мы оставляем)

для каждой связанной JOIN-ом таблицы из тех, чьи первичные ключи не входят
в (1), нужно добавить в GROUP BY первичный ключ этой при-JOIN-енной таблицы.

Получившийча запрос БУДЕТ НАРУШАТЬ ПРАВИЛА СТАНДАРТА ANSI SQL и не
будет переносим, кроме этого, такие запросы могут вызывать очень серьёзные
проблемы с производительностью, т.е., грубо говоря, очень долго выполняться.

Это связано как раз с этим "дополнением" ASE для GROUP BY.
Описано это здесь
и в последующих главах. Читайте и изучайте сами. Вкратце -- такие запросы
могут вызывать выполнение декартового произведения результата группировки
обратно с одной или несколькими исходными таблицами с данными, причём БЕЗ
применения каких-либо условий, что, понятно, очень опасно при даже достаточно
небольших таблицах типа 10 - 100 тысяч записей.

Поэтому НЕОБХОДИМО ОБЯЗАТЕЛЬНО ПРОВЕРЯТЬ ПЛАН ЗАПРОСА И ТЕСТИРОВАТЬ ЕГО
ПРОИЗВОДИТЕЛЬНОСТЬ ПЕРЕД ВНЕДРЕНИЕМ В РАБОЧУЮ СИСТЕМУ. На плане всегда
видны дополнительные незапланированные JOIN-ы.

cherrex_Den пишет:

> прочитал все и ссылку, но проблемы с производительностью могут поджидать
> только если будет ошибка в запросе (будет происходить декартовое
> произведение) либо сам по себе такой запрос(без ошибки и без
> декарт.произведения) трудоёмок для ASE?
>

Ни то, и ни другое. Запрос будет БЕЗ ОШИБКИ в том смысле, что
это никак не будет сообщено разработчику (кроме случая, когда set fipsflagger
on), и это является ожидаемым поведением ASE с точки зрения разработчиков
сервера. Но многие разработчики даже не подозревают о таков мозможном
поведении ASE, вот в чём проблема.

Что на счёт трудоёмкости - если там будет неявное декартово произведение,
оно всегда для любой СУБД трудоёмко. Просто потому, что много записей.
Если не будет - то производительность будет нормальной. Надо только
"правильно" написать запрос, а, поскольку в случае "неправильного" запроса
ASE ничего не говорит, то, чтобы всё было хорошо, надо очень тщательно
протестировать запрос, посмотреть план, IO, и пр. и убедиться, что всё хорошо.

> а такой способ прокатит? Ну если даже не выдержан стандарт SQL, а все
> равно не хватает(больше 600)

В принципе должен работать, но вы же будете генерировать больше строк,
чем нужно, в промежуточной таблице, потом её читать, а это всё лишний
IO. Не думаю, что это - лучший способ. Уж если идти таким путём, можно
сделать временную таблицу с идентификаторами и агрегатами, а потом
к ней при-JOIN-ить все остальные атрибуты для показа.
Posted via ActualForum NNTP Server 1.4

cherrex_Den пишет:

> а такой способ прокатит? Ну если даже не выдержан стандарт SQL, а все
> равно не хватает(больше 600)

Ну это как-то очень странно, что ж у вас за ключи такие длинные ?
А так (отвечаю всем) - ну да, можно во временные таблицы сагрегировать,
но это -- лишнее IO и потом не всегда можно временную таблицу использовать.
Я хотел предложить решение, которое всегда применимо, в любом запросе.
Posted via ActualForum NNTP Server 1.4

cherrex_Den пишет:

> 1.сводим все ключи и делаем GROUP BY по ключам( GROUP BY содержал все
> поля группы (1) и для каждой связанной JOIN-ом таблицы из тех, чьи
> первичные ключи не входят в (1), нужно добавить в GROUP BY первичный
> ключ этой при-JOIN-енной таблицы.) и кладем во времянку.
> 2.потом по ключам которые не входят в группу 1 делаем join-ы.

Я не понял, что там за "времянка". Либо вы пишите нормальный ANSI GROUP BY,
и вам никакого "правильного алгоритма" не надо, либо вы пишите не ANSI GROUP BY,
но там уже никаких временных таблиц не нужно.
Posted via ActualForum NNTP Server 1.4

cherrex_Den пишет:

> По ANSI GROUP BY все замечательно только может произойти казус "The
> current query would generate a key size of ...".
> По не ANSI GROUP BY казус очень редкий, но есть вероятность ошибки, и
> нужно делать через временную таблицу.
>
> Так, да?

Да нет, не так. Кто вам что про временную таблицу -то говорил ?

Ещё раз. У вас два пути.

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

Написать НЕ-ANSI GROUP BY, тогда никаких временных таблиц не нужно.
Но его нужно отлаживать тщательно.

вы может быть уже лучше запрос бы показали , а то я чувствую что по третему
кругу уже пойдём.
Posted via ActualForum NNTP Server 1.4