Ex_SoftЯ в субасю пришел недавно. Проанализировав имеющиеся ;) SP, обнаружил, что старшие товарисчи активно юзают временные таблицы для подготовки выборок, где можно обойтись, IMHO, всего лишЪ одним select'ом с парой-тройкой join'ов.


Можно только посочувствовать. Не умели они видимо запросы писать.

Ex_Soft
Аргументируется это так: субася, по крайней мере, большая (как они называют ASE), с которой я работаю, пльохо переваривает select'ы с join'ами на больших выборках (обЪемах данных). От их обилия у нее кружиться гольова, она входит в ступпор и ложиться. А, вот, с временными таблицами все бегает на ура.


Бред полный. Просто товарищи не умеют писать и оптимизировать запросы.

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

Ex_Soft
Эт в самом деле так или это досужие субЪективные заметки? ...
вопрос (типа: "...если слон и вдруг на кита налезет, кто кого сборет?.." ;) ). Тем паче, что субасю нам позиционировали как одну из самых шустрых СУБД. Особенно на больших обЪемах данных.


ASE - нормальная промышленная СУБД. Я не могу сказать, что она там типа "круче всех остальных в сто раз". Для этого нужно иметь какие-то доводы, результаты сравнений и прочее. Да и думаю в условиях конкурентной борьбы за рынок все СУБД примерно держаться в одном строю по возможностям.

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

Dim2000
Вопрос, конечно, интересный . Я немного имел дело с ASE на траверзе
11.5...11.9.2 - и в них оптимизатор был глупее фонарного столба (а с
Fullscan-ом, который он любил больше, чем мой кот сосиски, дело обстояло
ещё хуже).

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

В общем, тут можно наверное долго спорить, хороший оптимизатор или плохой, я - не буду. Спать хочу.

White Owl
Это кстати, очень и очень серьезный плюс в сторону использования временных таблиц. Лично я стараюсь не делать соединения более двух-трех таблиц в одном запросе.


Сознательно на этапе создания запроса ограничивать себя в количестве таблиц в запросе - это полный бред. Я не знаю, конечно, как ведет себя ASA, но в ASE это просто не нужно.

White Owl
Хотя если сложный запрос сумеет уложиться в оптимизаторе - почему бы и нет? :)
Вот именно. А если запрос имеет четкие критерии выборки, он гарантированно "уложиться".

White OwlТы не понял. Дело не столько в "думании за оптимизатор" сколько в читабельности запроса. Если запрос не умещается на одном экране текстового редактора - я его стараюсь разрезать на два, даже если это и не особо нужно с точки зрения оптимизации :) Исключительно с точки зрения читабельности.

Тут сложно. Из простых способов повышения читаемости могу предложить написать нужные VIEW. Но делать это надо аккуратно, ничего кроме JOIN-ов и фильтраций нельзя туда запихивать. А вообще я уже давно понял, что (увы) SQL - не язык для создания читаемых и модульных программ. Так что достигать там читаемости можно разве что в том смысле, что не создавать лишней нечитаемости. Пробелы там , отступы и пр. А больше - увы, нельзя. Я это в том смысле, что если мне предложат два варианта запроса - медленно работающий и нечитаемый - я выберу нечитаемый.

запросе для ASE я слышал, причём от людей с весьма приличным опытом
использования ASE. Да и сам видел, что делают с ASE 11.9.2 запросы,
которые для SA 5.5 никакой сложности не составляли.

Это были ламера от ASE. :))
Не, кроме шуток, я имею очень приличный опыт общения с ASE, но я бы ни за что не давал такие прямолинейные советы (кстати не только об ASE). Потому что на самом деле все зависит от конкретных запросов очень сильно.

А вот так и отлажывают, как вы написали. Я абсолютно со всем согласен, только что уж тут поделать. Такой язык SQL замечательный, и настолько структурный, что фиг его на части разделишь. Даже подзапрос не всегда написать можно. Но идя другим путем (временные таблицы) можно так завременнотабличиться, что уже под конец сам перестанешь соображать где какая таблица и какое поле.

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

[quot DrNull]
На все поля индексов не настроишь, а если одна таблица в объединении пойдет не по индексу... Результат будет плачевен, особенно если основные сканы пойдут как раз по ней.

Они все равно пойдут, разбит запрос или не разбит, по ней, если нет нужного
индекса.

Так же бывают нередки ситуации, когда объем поднимаемых в кеш индексов таблиц настолько велик, что не может туда поместиться - опять весь запрос свалится в скан.

Вот это - полная ерунда, оптимизатор работает без учета объема и доступности кэша. Он в отношении кэша он выбирает только размер IO. Так что запрос не может принципиально "свалиться в скан" из-за заполненности кэша. Да и вообще заполненность кэша -- это нормальная ситуация, зачем же он еще нужен. Так что будет ваш запрос все равно идти по индексу, вытесняя из кэша все остальное.

Поэтому, ИМХО, не стоит пугаться #таблиц, все равно Sybase строит итоговую таблицу для результатов запроса.

Отнюдь не всегда.

ДУМАТЬ и вытаскивать в #таблицы данные, позволяющие максимально эффективно "зажать" итоговый селект по высокопроизводительному (высокоселективному) индексу.

Думать - это хорошо всегда.