Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: Быстродействие  [new]
Glory
Member

Откуда:
Сообщений: 104760
SFlash

Видите только конкретную UDF и не видите что данный прием позволяет обойтись вообще без нее.

И что же вы предлагаете подставить вместо CREATE FUNCTION ?
13 авг 09, 14:22    [7533633]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
SFlash
Member

Откуда:
Сообщений: 143
Алексей2003,

А то что можно сразу в ХП это засунуть.

Вот пример одной РАБОЧЕЙ ХП
USE [PRD1]
GO
/****** Объект:  StoredProcedure [WH1].[sp_pallist]    Дата сценария: 08/13/2009 14:21:50 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROC [WH1].[sp_pallist]

@PORDERKEY as varchar(10),
@PCOUNT as int

as
declare @I as int
declare @SSQL nvarchar(2000)
set @I=@PCOUNT
set @SSQL='select orderkey, externorderkey, company, isnull(address1,'''')+'''+' '+'''+isnull(address2,'''')  fulladdress from orders
left join storer on (orders.consigneekey=storer.storerkey)
where orderkey='''+@PORDERKEY+''''
set @I=@I-1
WHILE @I>0
BEGIN
 set @SSQL=@SSQL+' UNION ALL select '''', '''', '''', '''''
 set @I=@I-1
END
exec sp_sqlexec @SSQL
13 авг 09, 14:26    [7533664]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
SFlash
Алексей2003,

А то что можно сразу в ХП это засунуть.

Вот пример одной РАБОЧЕЙ ХП
USE [PRD1]
GO
/****** Объект:  StoredProcedure [WH1].[sp_pallist]    Дата сценария: 08/13/2009 14:21:50 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROC [WH1].[sp_pallist]

@PORDERKEY as varchar(10),
@PCOUNT as int

as
declare @I as int
declare @SSQL nvarchar(2000)
set @I=@PCOUNT
set @SSQL='select orderkey, externorderkey, company, isnull(address1,'''')+'''+' '+'''+isnull(address2,'''')  fulladdress from orders
left join storer on (orders.consigneekey=storer.storerkey)
where orderkey='''+@PORDERKEY+''''
set @I=@I-1
WHILE @I>0
BEGIN
 set @SSQL=@SSQL+' UNION ALL select '''', '''', '''', '''''
 set @I=@I-1
END
exec sp_sqlexec @SSQL

1. ну так генерится процедуру на лету каждый раз. но видимо зачем то нужна вьюшка.
т.е. вызов select * from object
2. ну так сразу и показывайте пример с create procedure, а не create function.
13 авг 09, 14:30    [7533698]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
а то у вас получается, что вы предлагаете соединить машины шелковой ниткой. а что, соединяются..

для спящего время бодрствования равносильно сну
13 авг 09, 14:31    [7533711]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
SFlash
Member

Откуда:
Сообщений: 143
Алексей2003,
автор

1. ну так генерится процедуру на лету каждый раз. но видимо зачем то нужна вьюшка.
т.е. вызов select * from object
2. ну так сразу и показывайте пример с create procedure, а не create function.


В самом начале темы было описано что вызывается UDF для выборки из View в таблицу, а потом ХП от таблицы. Тут же исключается UDF так как execsql можно в саму ХП сунуть.
13 авг 09, 14:33    [7533729]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
2Shovgenyuk
и все таки я не могу понять, зачем в функции писать владельца схемы, если можно не указывать владельца при выборке. и будет по умолчанию подставляться владелец - юзер, если его нет , то dbo.
в итоге если таблиц от dbo у нас нет в базе, то будут возникать ошибки. и никто не забудет про свои таблицы. и не надо будет генерить функции каждый раз при новом пользователе.

для спящего время бодрствования равносильно сну
13 авг 09, 14:36    [7533752]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
SFlash
Member

Откуда:
Сообщений: 143
Алексей2003
2Shovgenyuk
и все таки я не могу понять, зачем в функции писать владельца схемы, если можно не указывать владельца при выборке. и будет по умолчанию подставляться владелец - юзер, если его нет , то dbo.
в итоге если таблиц от dbo у нас нет в базе, то будут возникать ошибки. и никто не забудет про свои таблицы. и не надо будет генерить функции каждый раз при новом пользователе.

для спящего время бодрствования равносильно сну


Наконец то!!!!
Долго я ждал пока кто нибудь это озвучит. :)
13 авг 09, 14:40    [7533785]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
SFlash
Алексей2003
2Shovgenyuk
и все таки я не могу понять, зачем в функции писать владельца схемы, если можно не указывать владельца при выборке. и будет по умолчанию подставляться владелец - юзер, если его нет , то dbo.
в итоге если таблиц от dbo у нас нет в базе, то будут возникать ошибки. и никто не забудет про свои таблицы. и не надо будет генерить функции каждый раз при новом пользователе.

для спящего время бодрствования равносильно сну


Наконец то!!!!
Долго я ждал пока кто нибудь это озвучит. :)

ваша динамика там совершенно не нужна.
13 авг 09, 14:42    [7533800]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
вообще возвращаясь к теме вопроса.
если данные динамические запросы НЕ избежать уже. тогда при большом количестве мелких запросов, система будет висеть. при небольшом количестве крупных запросов, системе будет ~параллельно.

для спящего время бодрствования равносильно сну
13 авг 09, 14:45    [7533825]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
x-x
Member

Откуда:
Сообщений: 230
SFlash
Наконец то!!!!
Долго я ждал пока кто нибудь это озвучит. :)

Позвольте спросить - зачем?
Алексей2003
2Shovgenyuk
и все таки я не могу понять, зачем в функции писать владельца схемы, если можно не указывать владельца при выборке. и будет по умолчанию подставляться владелец - юзер, если его нет , то dbo.
в итоге если таблиц от dbo у нас нет в базе, то будут возникать ошибки. и никто не забудет про свои таблицы. и не надо будет генерить функции каждый раз при новом пользователе.
Смотря какая система права у товарища.
13 авг 09, 14:47    [7533837]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
x-x
Member

Откуда:
Сообщений: 230
x-x
Смотря какая система прав у товарища.
13 авг 09, 14:47    [7533848]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Shovgenyuk
Member

Откуда: Ивано-Франковск-Киев
Сообщений: 462
Glory

Если запрос и так будет формироваться динамически для каждого вызова, то зачем еще лепить шаг записи его в представление ? Чтобы еще увеличить накладные расходы на создание объекта, обработку результата создания и тп ? Чтобы увеличить административные расходы по поддержанию нужных прав на такие действия ?


iljy

ИМХО схема излишне сложная, причем совершенно неоправданно. Вы все равно часть запроса формируете в динамике при создании VIEW, так зачем извращаться? Лучше оберните вьюхой общую часть, а сам запрос с фильтрами создавайте на клиенте. Если нужна дальнейшая обработка процедурами - сохраните результат во временную таблицу перед вызовом хранимки.


Сложилась такая схема в результате моих усилий как-то обойти динамический SQL. Я понимаю, что хотя и на сервере нет явно динамического SQL, всё равно по сути он есть динамический.
Запрос формируется не для каждого вызова, а только тогда когдапользователь решил изменить параметры фильтра.
Если я сохраню результат динамического запроса в таблицу ето будет быстрее чем использовать сам View вместо таблицы?
На вставку в таблицу ведь также нужно время. Результатом запроса могут быть сотни тысяч строк.
13 авг 09, 14:48    [7533849]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
x-x

Алексей2003
2Shovgenyuk
и все таки я не могу понять, зачем в функции писать владельца схемы, если можно не указывать владельца при выборке. и будет по умолчанию подставляться владелец - юзер, если его нет , то dbo.
в итоге если таблиц от dbo у нас нет в базе, то будут возникать ошибки. и никто не забудет про свои таблицы. и не надо будет генерить функции каждый раз при новом пользователе.
Смотря какая система права у товарища.

да, тоже верно. если dbo сделает запрет на все свои таблицы, то система все равно будет ругаться, но правда на недостаток прав при наличии таблицы.
13 авг 09, 14:48    [7533851]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Shovgenyuk
Member

Откуда: Ивано-Франковск-Киев
Сообщений: 462
Алексей2003
2Shovgenyuk
и все таки я не могу понять, зачем в функции писать владельца схемы, если можно не указывать владельца при выборке. и будет по умолчанию подставляться владелец - юзер, если его нет , то dbo.
в итоге если таблиц от dbo у нас нет в базе, то будут возникать ошибки. и никто не забудет про свои таблицы. и не надо будет генерить функции каждый раз при новом пользователе.

для спящего время бодрствования равносильно сну


Да, тут я дал маху....
СПАСИБО :)
13 авг 09, 14:50    [7533867]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Shovgenyuk
Member

Откуда: Ивано-Франковск-Киев
Сообщений: 462
Затерялся мой вопрос в постах....
С UDF я понял, ето для меня полезно, но не это было основное.

Если я сохраню результат динамического запроса в таблицу ето будет быстрее чем использовать сам View вместо таблицы?
На вставку в таблицу ведь также нужно время. Результатом запроса могут быть сотни тысяч строк.
14 авг 09, 11:48    [7538205]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Glory
Member

Откуда:
Сообщений: 104760
Shovgenyuk

Если я сохраню результат динамического запроса в таблицу ето будет быстрее чем использовать сам View вместо таблицы?
На вставку в таблицу ведь также нужно время. Результатом запроса могут быть сотни тысяч строк.

Вы не понимаете сути
Задача выборки с переменным числом критериев имеет 2 способа решения
- динамический запрос только с действительно выбранными фильтрами
- явный запрос с маскированием незаданных фильтров

И нет никакой разницы для первого способа, как конкретно вы там его реализуете - сразу выполните запрос или поместите его текст в представление и выполните или выполните с размещением результата в таблице. Все равно будет 2 шага - формирование+выполнение. Если вам хочется между этими двумя шагами вставить еще дополнительные шаги, то никто вам не мешает. Только глупо рассчитывать на то, что эти дополнительные шаги увеличат быстродействие. Потому что не может большее число действий выполняться за меньшее время.

А вот зачем клиенту в результатх "сотни тысяч строк" - непонятно. Он их будет в гриде у себя скролить что ли ? Не упарится на стрелки жать ?
14 авг 09, 12:03    [7538335]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Shovgenyuk
Member

Откуда: Ивано-Франковск-Киев
Сообщений: 462
Glory

Вы не понимаете сути
Задача выборки с переменным числом критериев имеет 2 способа решения
- динамический запрос только с действительно выбранными фильтрами
- явный запрос с маскированием незаданных фильтров

И нет никакой разницы для первого способа, как конкретно вы там его реализуете - сразу выполните запрос или поместите его текст в представление и выполните или выполните с размещением результата в таблице. Все равно будет 2 шага - формирование+выполнение. Если вам хочется между этими двумя шагами вставить еще дополнительные шаги, то никто вам не мешает. Только глупо рассчитывать на то, что эти дополнительные шаги увеличат быстродействие. Потому что не может большее число действий выполняться за меньшее время.

А вот зачем клиенту в результатх "сотни тысяч строк" - непонятно. Он их будет в гриде у себя скролить что ли ? Не упарится на стрелки жать ?


Понимаю я суть, но у меня конкретный вопрос если запрос возвращает много (сотни тис.) строк, не будет ли быстрее использовать сам запрос вместо того что бы вставлять ети строки во временную таблицу и потом использовать её?

Клиенту ети строки не нужны, но они обрабатываються в SP и уже после неё к клиенту попадает меньше данных.
14 авг 09, 12:19    [7538513]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Glory
Member

Откуда:
Сообщений: 104760
Shovgenyuk


Понимаю я суть, но у меня конкретный вопрос если запрос возвращает много (сотни тис.) строк, не будет ли быстрее использовать сам запрос вместо того что бы вставлять ети строки во временную таблицу и потом использовать её?

Да не фига вы не понимаете, если не можете понять, что select into+select выполняются дольше, чем просто select.
14 авг 09, 12:23    [7538543]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Shovgenyuk
Member

Откуда: Ивано-Франковск-Киев
Сообщений: 462
Glory

Да не фига вы не понимаете, если не можете понять, что select into+select выполняются дольше, чем просто select.


Я не знаю как сервер работает там "внутри". Возможно при виполнении "большого" select сервер автоматически создает временную таблицу, и в таком случае если я создам ету временную таблицу явно ( into+select), то ето ничем не будет медленние чем то что сервер её сам создаст.
14 авг 09, 12:34    [7538643]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Glory
Member

Откуда:
Сообщений: 104760
Shovgenyuk
Glory

Да не фига вы не понимаете, если не можете понять, что select into+select выполняются дольше, чем просто select.


Я не знаю как сервер работает там "внутри". Возможно при виполнении "большого" select сервер автоматически создает временную таблицу, и в таком случае если я создам ету временную таблицу явно ( into+select), то ето ничем не будет медленние чем то что сервер её сам создаст.

Что "уней унутре" показывает план выполнения.
А что такое "большой" select ?
Вы хотите из миллионной таблицы по какому-то критерию выбрать 100тыс и положить в промежуточную таблицу ? А потом из стотысячной таблицы выбрать еще 1000 записей ? И снова в промежуточную таблицу ? И в итоге пользователю придет пара записей ?
14 авг 09, 12:43    [7538723]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Shovgenyuk
Member

Откуда: Ивано-Франковск-Киев
Сообщений: 462
Glory

А что такое "большой" select ?

"большой" select - то что описал, сотни тысяч строк.

Glory

Вы хотите из миллионной таблицы по какому-то критерию выбрать 100тыс и положить в промежуточную таблицу ? А потом из стотысячной таблицы выбрать еще 1000 записей ? И снова в промежуточную таблицу ? И в итоге пользователю придет пара записей ?

В общем да, и мне интересно как лутче: использовать при этом только вюверы или вювер+временная таблица.
14 авг 09, 12:56    [7538819]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Glory
Member

Откуда:
Сообщений: 104760
Shovgenyuk

Glory

Вы хотите из миллионной таблицы по какому-то критерию выбрать 100тыс и положить в промежуточную таблицу ? А потом из стотысячной таблицы выбрать еще 1000 записей ? И снова в промежуточную таблицу ? И в итоге пользователю придет пара записей ?

В общем да, и мне интересно как лутче: использовать при этом только вюверы или вювер+временная таблица.

А вы план выполнения своего запроса видели прежде, чем решили за сервер решать, в какой последовательности и как именно он должен выполнять этот запрос ?
А вы в курсе, что неиндексированные представления сервер раскрывает до базовых таблиц и работает с ними так, как если бы текст запроса был сразу написан для этих таблиц?
14 авг 09, 13:01    [7538865]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Shovgenyuk
Member

Откуда: Ивано-Франковск-Киев
Сообщений: 462
Glory, если бы я был вкурсе всего, то я бы здесь эти вопросы просто так не задавал )
14 авг 09, 13:06    [7538911]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Glory
Member

Откуда:
Сообщений: 104760
Shovgenyuk
Glory, если бы я был вкурсе всего, то я бы здесь эти вопросы просто так не задавал )

Т.е. вы сейчас впервые узнали, что у всех запросов есть планы выполнения, из которых видно, "как сервер работает там "внутри" ?
14 авг 09, 13:13    [7538973]     Ответить | Цитировать Сообщить модератору
 Re: Быстродействие  [new]
Shovgenyuk
Member

Откуда: Ивано-Франковск-Киев
Сообщений: 462
Нет не впервые )
Но это может помочь решить вопросы только с конкретными случаями, я хотел узнать возможно есть какие-то общие рекомендации.
Например, типа такого "для select с количеством сток больше 100 000 или размером больше 5Мб, сервер всегда создаёт временную табл."

Про индексы во вюверах я узнал впервые.
14 авг 09, 13:20    [7539034]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить