PaulWist
Только не работает приведенный код

Работает, работает. Только решает другую задачу.

leonid

PaulWist
Только не работает приведенный код

Работает, работает. Только решает другую задачу.

Леонид, если считаешь что с поставленный код справляется с задачей, я не возражаю.

PS думаю на этом можно поставить точку.





Исправлено 1 раз(а). Последнее : PaulWist, 16.03.07 12:07

Prudivus
Повторюсь:

Цитата:

Кластеризация необязательна, если речь идет о временных таблицах (или переменных-таблицах), проверено на работающей задаче.

Ты хоть код мой запускал?

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


То есть когда можно явно задать сортировку результирующего курсора.

Приведенный код весьма не разумен, побочным явлением его является перекомпиляция ХП, при встрече с инструкцией


те если у тебя в ХП 10 таких вызовов то тебе обеспечино 10 перекомпиляций и соответственно тормоза при выполнении, правда это существенно заметно если сама ХП имеет приличный размер.

Насчет "неразумности" весьма спорно. Да, перекомпиляция будет, но при сравнении с вариантом выборки в таблицу-переменную


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

Prudivus
Насчет "неразумности" весьма спорно. Да, перекомпиляция будет, но при сравнении с вариантом выборки в таблицу-переменную

Что-ж из этих слов можно сделать вывод, что в твоей практике не было ХП размером больше 100 строк, с использованием временных таблиц или таблеваров.

На самом деле перекомпиляция ХП весьма ресурсоемкий процесс.

Цитата:

Что-ж из этих слов можно сделать вывод, что в твоей практике не было ХП размером больше 100 строк, с использованием временных таблиц или таблеваров.

Вывод довольно странный. Хотя количеством строк меряться не буду - это тот случай когда количество не переходит в качество. ;)

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

Для интереса поглядел на один триггер, с использованием двух временных таблиц и одной таблицы-переменной: 269 строк, при этом еще вызываются дополнительные ХП, реализующие специфическую бизнес-логику (то самое связывание, только гораздо сложнее чем было в примере). Время выполнения вполне приемлемое, в эту таблицу вводятся данные, время реакции в клиенте - порядка секунды на миллионных объемах.

Prudivus

Цитата:

Что-ж из этих слов можно сделать вывод, что в твоей практике не было ХП размером больше 100 строк, с использованием временных таблиц или таблеваров.

Вывод довольно странный. Хотя количеством строк меряться не буду - это тот случай когда количество не переходит в качество. ;)

Без обид, просто твоё неверие говорит, что ты с этим не сталкивался, я сам совсем недавно столкнулся, когда ХП стали больше 1 тыс строк.

forum.foxclub.ru

ну или здесь

www.sql.ru

Нет, никаких обид. Без временных таблиц очень трудно обойтись. Хотя бы для того чтобы передавать данные в ХП. Скажем, есть некая ХП (на пару сотен строк), в которой делается непростой расчет, и которая может вызываться из нескольких мест (триггеров и ХП), в нее нужно передавать массивы строк. Как? Временные таблицы.

Да, знаю, что можно создать специальную (постоянную) таблицу(ы) для передачи и т.п. Но имхо - не стоит, если речь о системе где передачи массивов встречаются часто и итоговое быстродействие устраивает. По поводу перекомпиляции ХП на 1000 строк, может быть и долго, особенно если она вызывается из триггера. Как вариант - сделать декомпозицию, разбить на несколько более мелких, если возможно. Но тебе, я думаю, виднее как лучше в твоем случае.