Здравствуйте, Sinclair, Вы писали:

S>Итак, в синем углу ринга — ... неоднократный ... бессменный ... автор ... статей и ... избранных сообщений.
А еще у меня пушка.

Здравствуйте, Kvazimodo75, Вы писали:

K>Все эти решения уничтожают главное, для чего делается хранимка — предварительная компиляция запроса.
Хранимки не компилируют запрос предварительно.
Запросы всегда компилируются отдельно и лежат в своем кеше, не вожно — в хранимке этот запрос или из кода пришел.


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

Здравствуйте, IB, Вы писали:

IB>Хранимки не компилируют запрос предварительно.

BOL:

If the operation requires a large amount of Transact-SQL code or is performed repetitively, stored procedures can be faster than batches of Transact-SQL code. They are parsed and optimized when they are created, and an in-memory version of the procedure can be used after the procedure is executed the first time. Transact-SQL statements repeatedly sent from the client each time they run are compiled and optimized every time they are executed by SQL Server.

Здравствуйте, Kvazimodo75, Вы писали:

K>Здравствуйте, IB, Вы писали:

IB>>Хранимки не компилируют запрос предварительно.

K>BOL:
K>

K>If the operation requires a large amount of Transact-SQL code or is performed repetitively, stored procedures can be faster than batches of Transact-SQL code. They are parsed and optimized when they are created, and an in-memory version of the procedure can be used after the procedure is executed the first time. Transact-SQL statements repeatedly sent from the client each time they run are compiled and optimized every time they are executed by SQL Server.

Это от какой версии BOL? От 6.5?
В новом ничего подобного я найти не могу: http://msdn2.microsoft.com/en-us/library/ms191436.aspx
Более того, начиная с 7.0 было explicitly указано, что теперь SQL Server пересматривает план хранимки при каждом вызове, чтобы вовремя сменить его, если оно того стоит для данных запросов.

Здравствуйте, Kvazimodo75, Вы писали:

K>BOL:
K>

K>If the operation requires a large amount of Transact-SQL code or is performed repetitively, stored procedures can be faster than batches of Transact-SQL code. They are parsed and optimized when they are created, and an in-memory version of the procedure can be used after the procedure is executed the first time. Transact-SQL statements repeatedly sent from the client each time they run are compiled and optimized every time they are executed by SQL Server.

parsed and optimized when they are created — означает, что хранимка разбирается на запросы и запросы отдельно кладутся в кеш. Код процедуры не компилируется и ее логика интерпретируется при каждом вызове.
По поводу того что запос compiled and optimized every time they are executed by SQL Server — это просто ошибка в BOL, все скомпилированные планы запросов всегда кешируются совершенно одинаково, вне зависимости от того откуда они пришли. Это хорошо видно в соответствующих системных таблицах, соответствующие MSDN-овские статьи мне сейчас лень искать.
Таким образом, хранимка может быть быстрее обычного запроса только за счет того, что текст запроса длиннее, чем вызов хранимки.

Здравствуйте, IB, Вы писали:

А>>4. ну и наконец область видимости — таблица должна быть видима во всех процедурах,
IB>Таблица, опять-таки, никому ничего не должна. Область видимости временных таблиц и табличных переменных в сиквеле ограничена процедурой или подключением. И это правильно.

Неправильно. Глобальные временные таблицы (##) видны всем.

Здравствуйте, Lloyd, Вы писали:

L>Неправильно. Глобальные временные таблицы (##) видны всем.
Ну я-то писал про временные таблицы, а не про глобальные временные таблицы.

Здравствуйте, IB, Вы писали:

L>>Неправильно. Глобальные временные таблицы (##) видны всем.
IB>Ну я-то писал про временные таблицы, а не про глобальные временные таблицы.

Вообще-то временные таблицы — это локальные временные таблицы (#) + глобальные временные таблицы (##). Поэтому все-таки не неправильно.

Здравствуйте, Lloyd, Вы писали:

L>Вообще-то временные таблицы — это локальные временные таблицы (#) + глобальные временные таблицы (##). Поэтому все-таки не неправильно.
Буквоед и зануда..

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Sinclair, Вы писали:

S>>Итак, в синем углу ринга — ... неоднократный ... бессменный ... автор ... статей и ... избранных сообщений.
IB>А еще у меня пушка.
Ну здесь не чего добавить!

Пусть тогда за тебя говорят твой Кольт!

Здравствуйте, IB, Вы писали:

L>>Вообще-то временные таблицы — это локальные временные таблицы (#) + глобальные временные таблицы (##). Поэтому все-таки не неправильно.
IB>Буквоед и зануда..

Вот теперь правильно.

А>>1. передавать вложенные структуры.
IB>Вложенные во что? Какой размерности должен быть этот массив?
включите мозг, догадаетесь во что. двухмерности вполне досточно, хотя для ГИС можно и 3

А>>2. это должна быть стуктура в памяти, как и все переменные, чтоб избежать конкуренции и/о в tempdb в котором и так чего только нет — от сортировок до юлозания тригеров и версионности.
IB>Ты предлагаешь весь тот мусор, который хранится в переменных, держать в памяти в ущерб другим данным? Оригинально.
именно, память — она резиновая, а заниматся сексом с i/o tempdb очень дорого.

IB>Эта структура никому ничего не должна, она должна хранится там где удобно сиквелу. Никакой лишней конкуренции это не вызовет, tmpdb специально предназначена для таких вещей и разрабатывалась с учетом именно такой нагрузки.
о, да — никаой лишней конкуренции. вот читаю и проникаюсь уважением к архитекторам:
One of challenges in managing tempdb is that there is no way to partition its resources based on user databases, applications, or user sessions. You cannot even partition resources based on the category of objects (such as version stores) that are stored.
http://download.microsoft.com/download/4/7/a/47a548b9-249e-484c-abd7-29f31282b04d/WorkingWithTempDB.doc

А>>3. это должна быть стуктура в памяти, чтоб избежать чудовищного расхода ресурсов: писания логов, перекомпиляция процедур, сбор статистики для оптимизатора и т.п.
IB>Временные структуры, типа VSH, в лог не пишутся, перекомпиляция процедур тут вообще не причем, равно как и статистика для оптимизатора.
непонял, что такое VSH ? будешь спорить, что temporary tables и table variables пишут лог ? вызывают перекомпиляцию, может с тем что на временные таблицы собирается статистика ?

IB>Не смотря на то, что tempdb выглядит как обычная БД — это совершенно отдельная структура, оптимизированная под работу в качестве временного хранилища служебных данных.
оптимизировано оно на уровне рекламных брошюр — не более.

IB>Если для целостности данных необходимо, чтобы велся лог и статистика, значит они будут там вестись, если такой необходимости нет — то не будут. Не считай себя умнее разработчиков сиквела.
зачем мне лог и статистика на структуру которую я хочу лишь передать в процедуру или вернуть(получить) на клиент ?? естественно я умнее просто по тому, что знаю что нужно моему приложению, но меня заставляют использовать совершенно не присобленую под поставленые задачи temporary table

А>>4. ну и наконец область видимости — таблица должна быть видима во всех процедурах,
IB>Таблица, опять-таки, никому ничего не должна. Область видимости временных таблиц и табличных переменных в сиквеле ограничена процедурой или подключением. И это правильно.
мда ? область видимости у вас у table variables и temporary tables ограничена процедурой ? давно ?

Здравствуйте, Аноним, Вы писали:

А>включите мозг,
Мне только нехватало напрягать свой мозг, чтобы догадываться что ты там придумал.

A> двухмерности вполне досточно,
Тогда вернемся к началу, так чем это отличается от таблицы?

A> хотя для ГИС можно и 3
И как оттуда данные доставать собираешься?

А>именно, память — она резиновая,
Ага. А своп придумали трусы.

А>о, да — никаой лишней конкуренции.
Именно.

А> вот читаю и проникаюсь уважением к архитекторам:
Давно пора.

А>One of challenges in managing tempdb is that there is no way to partition ...
И к чему это?

А>непонял, что такое VSH ?
Version Store Heap

A> будешь спорить, что temporary tables и table variables пишут лог ?
Пишут, но по разному. Переменные отмечаются только в чекпоинтах, на них даже rollback не действует. Сюрпрайз?

A> вызывают перекомпиляцию,
Не вызывают.

A>может с тем что на временные таблицы собирается статистика ?
На таблицы собирается, а на табличные переменные нет.

А>оптимизировано оно на уровне рекламных брошюр — не более.
Самое время начинать верить в рекламные брошюры.

А>зачем мне лог и статистика на структуру которую я хочу лишь передать в процедуру или вернуть(получить) на клиент ??
Еще раз: надо — будут, не надо — не будут. На табличные переменые, к примеру, в отличии от временных таблиц, статистика не ведется и в лог они не пишутся.

A>естественно я умнее просто по тому, что знаю что нужно моему приложению,
Не знаешь. ACID-ity либо есть, либо нет, вне зависимости от того, что нужно твоему приложению.

A> но меня заставляют использовать совершенно не присобленую под поставленые задачи temporary table
Не temporary table, а table variable, которая к задаче подходит идеально.

А>мда ? область видимости у вас у table variables и temporary tables ограничена процедурой ? давно ?
Слушай, у меня ощущение, что я открываю тебе новый мир.