Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Других корректных точно не помню (наверное, потому что по сравнению с этим они не убедительны ) но по смутным воспоминаниям выигрыш в несколько раз получался.
Это существенно зависит от того, что за база, что за отчеты, и так далее.
Скажем, не так давно человек меня убеждал, что единственный путь добиться скорости — все делать на хранимых процедурах. В результате из его объяснений выяснилось, что MS SQL не поддерживает binding параметров в SQL-запросах, вот и вся причина — чтобы не парсить постоянно запрос, его приходится обертывать в хранимку.
Здравствуйте, Softwarer, Вы писали:
S>В результате из его объяснений выяснилось, что MS SQL не поддерживает binding параметров в SQL-запросах, вот и вся причина — чтобы не парсить постоянно запрос, его приходится обертывать в хранимку.
Могу дать ссылку на обсуждение — сам, извини, не проверял, так что передаю слова этого человека, на которые никто не возразил. То же ADO делает такую обертку автоматом — есть какая-то хранимка, что-то типа execute_sql, специально для этого предназначенная. А BDE, по его словам, просто поставляет значения параметров на клиенте.
Здравствуйте, Softwarer, Вы писали:
S>Могу дать ссылку на обсуждение — сам, извини, не проверял, так что передаю слова этого человека, на которые никто не возразил. То же ADO делает такую обертку автоматом — есть какая-то хранимка, что-то типа execute_sql, специально для этого предназначенная.
ADO при включенном Prepare насколько я помню юзает sp_prepexec/sp_execute. Всегда был уверен что это штатный механизм parameter binding, но только что открыл для себя что эти хранимые процедуры не описаны в BOL. Мнда, удивительное рядом, извиняюсь что встрял.
Здравствуйте, Softwarer, Вы писали: S>Могу дать ссылку на обсуждение — сам, извини, не проверял, так что передаю слова этого человека, на которые никто не возразил. S>P.S. Я тоже был здорово удивлен
Давай ссылку. Щас разберемся, кто там что у кого не поддерживает
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Обратите внимание — человек даже сходу не поверил в трейс-файл от оракла, согласно которому запрос приходит на сервер без подстановки значений параметров вместо :1, :2.
Здравствуйте, Softwarer, Вы писали:
S>В результате из его объяснений выяснилось, что MS SQL не поддерживает binding параметров в SQL-запросах, вот и вся причина — чтобы не парсить постоянно запрос, его приходится обертывать в хранимку.
По-моему это прекратилось в SS 2000 — теперь кэшируется все, что парсится кем-либо и как-либо.
Здравствуйте, wildwind, Вы писали:
W>По-моему это прекратилось в SS 2000 — теперь кэшируется все, что парсится кем-либо и как-либо.
Хорошо если так. И очень плохо, что этого не было сразу. Правда, недавно мне рассказывали про collate в MS SQL — еще больше волосы дыбом встали
Собственно, мое впечатление следующее: профессионал должен работать со всем. То есть если что — надо будет работать именно с MS SQL. В то же время, если я вижу столь странные дырки — обычно я не трачу время на ознакомление со следующими версиями этой программы в надежде, что уж они-то будут хороши.
Здравствуйте, Softwarer, Вы писали:
S>Хорошо если так. И очень плохо, что этого не было сразу. Правда, недавно мне рассказывали про collate в MS SQL — еще больше волосы дыбом встали
Сейчас обещают, что все, что еще плохо, будет хорошо в Yukon .
S>В то же время, если я вижу столь странные дырки — обычно я не трачу время на ознакомление со следующими версиями этой программы в надежде, что уж они-то будут хороши.
Ну, в общем случае позиция спорная. Если бы все придерживались такого отношения, то ни один проект не смог бы встать крепко на ноги. (В Oracle тоже не все сразу появилось).
Здравствуйте, Softwarer, Вы писали: S>Вот собственно тема — но ее вряд ли интересно читать целиком.
О, спасибо. S>http://sql.ru/forum/actualthread.aspx?bid=20&tid=126144&pg=1&hl=bind#995179 S>Поэтому приведу ссылки на несколько "ключевых" писем — может быть, субъективно выбранных.
Ну, как только я дочитал до фрагмента (ссылки на этот форум ведут себя как-то странно, поэтому привожу цитату):
Блин, никто мне об этом не гоорил, я сам с этим сталкиваюсь. Если вернуться к приведенному выше примеру, то
SELECT
*
FROM
sysobjects
WHERE
id = 2
и
SELECT
*
FROM
sysobjects
WHERE
id = 123456
то это РАЗНЫЕ ЗАПРОСЫ. И чтоб иметь возможность повторного использования плана выполнения надо:
1. Или поместить этот запрос в хп.
2. Или завернуть его в sp_executesql, что в принципе равнзначно первому.
я понял, что товарищ с ником pkarklin, мягко говоря, заблуждается.
Мне сейчас недосуг листать BOL, но факт в том, что даже все константы MS SQL заменяет на искусственные переменные для того, чтобы брать план запроса из кэша.
Тем более это правда для биндинга параметров вида
SELECT
*
FROM
sysobjects
WHERE
id = @id
Поэтому рассуждения о преимуществе ХП перед батчами — мифы, неподкрепленные реальными аргументами.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>я понял, что товарищ с ником pkarklin, мягко говоря, заблуждается.
Насколько я в курсе, на sql.ru у него достаточно высокая репутация — я его знания оценить не в силах. Поэтому, предположу, вы скорее всего имеете в виду разные версии, разные настройки — просто потому, что оба производите впечатление компетентных специалистов.
Если вдруг решите это с ним обсудить — я с удовольствием почитаю. Он там присутствует постоянно, в частности, в форуме по MS SQL.
Здравствуйте, wildwind, Вы писали:
W>Ну, в общем случае позиция спорная. Если бы все придерживались такого отношения, то ни один проект не смог бы встать крепко на ноги. (В Oracle тоже не все сразу появилось).
Одно дело — "не появилось", а другое дело — "появившееся сделано плохо". Если первое — именно что вопрос времени (развития, итп), то второе — показывает некомпетентных специалистов либо наплевательский подход к результату, что скорее всего скажется и в следующих версиях.
Само собой, это не абсолют — скорее эвристика, которая помогает не утонуть в вариантах выбора. Если я что-то смотрел и мне не понравилось — я сначала посмотрю то, что еще не видел, и только потом, может быть, брошу второй взгляд на первый вариант.
Здравствуйте, Softwarer, Вы писали:
S>Одно дело — "не появилось", а другое дело — "появившееся сделано плохо". Если первое — именно что вопрос времени (развития, итп), то второе — показывает некомпетентных специалистов либо наплевательский подход к результату, что скорее всего скажется и в следующих версиях.
Все верно, если мы говорим о поделках студентов или начинаниях увлеченных идеей энтузиастов. Но у лидеров отрасли (в частности и особенно у MS) ни того ни другого не наблюдается в принципе. Тут действуют другие силы. И Oracle, так же как и MS, подгоняемая конкуренцией и технологической "гонкой вооружений", вынуждена выпускать новые фичи в своих продуктах сырыми и глючными. А потом, когда продукт уже выпущен, пресс-релизы разосланы, и пальма первенства удержана, доделывать, вылизывать, и умасливать недовольных патчами и сервис-паками. Это не так страшно, как упустить момент и потерять бОльшую часть нового рынка. Ничего, что потеряли тысячу старых разработчиков, зато приобрели десять тысяч новых! Хитрые старые лисы, пишущие бестселлеры по управлению IT бизнесом, видно не зря едят свой хлеб.
Здравствуйте, Softwarer, Вы писали: S>Насколько я в курсе, на sql.ru у него достаточно высокая репутация — я его знания оценить не в силах. Поэтому, предположу, вы скорее всего имеете в виду разные версии, разные настройки — просто потому, что оба производите впечатление компетентных специалистов.
Все может быть. Кстати, занятный факт: в BOL по MS SQL 7.0 в разделе What's new присутствовали, в частности, слова о том, что теперь
а) план хранимой процедуры пересматривается при каждом выполнении дабы учесть все изменения
б) константы в запросе заменяются переменными для повышения вероятности cache hit
А теперь (2k) ничего этого нет. Зато есть невнятные упоминания о том, что использование процедур повышает производительность. А также замечания типа того, что использование не-fully qualified names предотвращает cache hit!
Резюме: похоже, надо ставить эксперименты. С включением трейс флагов (по которым тут эксперт — Merle) дабы отследить собственно, что, куда и где попадает.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>а) план хранимой процедуры пересматривается при каждом выполнении дабы учесть все изменения
Хм. Имхо это будет дороговато.
S>б) константы в запросе заменяются переменными для повышения вероятности cache hit
В оракле есть соответствующий режим, но его не рекомендуется включать, чтобы эффективно использовать гистограммы. То есть идеальный подход выглядит как "переменные — параметрами, константы — константами". Это, естественно, подразумевает, что разработчик понимает, что делает, и не будет пихать константы туда, где нужен парамет.
S>А также замечания типа того, что использование не-fully qualified names предотвращает cache hit!
Хм. А в MS SQL есть понятие синонима? В Оракле есть момент, связанный с тем, что синонимы у разных пользователей могут относиться к разным объектам — и, соответственно, может потребоваться хранить и обсчитывать несколько планов для внешне одинаковых запросов.
Здравствуйте, Sinclair, Вы писали:
S>я понял, что товарищ с ником pkarklin, мягко говоря, заблуждается.
Да он там по жизни заблуждается, да и вообще, sql.ru для здоровья читать — вредно, до обеда..
S> Мне сейчас недосуг листать BOL, но факт в том, что даже все константы MS SQL заменяет на искусственные переменные для того, чтобы брать план запроса из кэша.
Именно так. Там есть некоторое магическое число, количество запросов с константами до которого он константы воспринимает именно как константы, а после заменяет на один параметризованный запрос..
Поэтому, предположу, вы скорее всего имеете в виду разные версии, разные настройки — просто потому, что оба производите впечатление компетентных специалистов.
Нету там вообще никаких настроек, и различия в поведении от версий тоже нет.
Здравствуйте, Softwarer, Вы писали:
S> То есть идеальный подход выглядит как "переменные — параметрами, константы — константами". Это, естественно, подразумевает, что разработчик понимает, что делает, и не будет пихать константы туда, где нужен парамет.
Идеальный подход для случая когда разработчик может заблуждаться применен у MSSQL'я. До какого-то момента, как я уже писал, сервер одни и те же запросы, но с разными костантами воспринимает как разные запросы, а потом заменяет это дело на одни параметризованый.
S>Хм. А в MS SQL есть понятие синонима?
Нет.
Здравствуйте, Merle, Вы писали:
M>Идеальный подход для случая когда разработчик может заблуждаться применен у MSSQL'я. До какого-то момента, как я уже писал, сервер одни и те же запросы, но с разными константами воспринимает как разные запросы, а потом заменяет это дело на одни параметризованый.
А насколько дорого это обходится в случае, когда разработчик не заблуждается?
С парсингом при этом вроде бы все достаточно в порядке — нужен дополнительный хэш типа "сколько запросов с таким параметризованным видом сейчас в кэше" и все. Смущает другое: в ситуации, когда в принципе предусмотрено вытеснение из кэша (то есть я не могу выделить под планы столько места, чтобы они никогда не вытеснялись) сервер может решить параметризировать те запросы, которые я настоятельно хотел бы оставить с константами. Или в MSSQL такое желание бессмысленно?
) но по смутным воспоминаниям выигрыш в несколько раз получался.
Мнда, удивительное рядом, извиняюсь что встрял.
Мы уже победили, просто это еще не так заметно...
