|
|
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
Hi all! Есть SP с несколькими параметрами например int и datetime Мне надо выбрать данные согласно этим параметрам. Проблеиа: если один или несколько параметров будут= NULL ясно ничего не выйдет. Как можно обойти использование sqlexec. Зараннее всем очень признателен :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 12:28:21 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 12:33:14 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
... WHERE (SomeIntField=@ParamInt or @ParamInt is NULL) and (SomeDateField=@ParamDate or @ParamDate is NULL) ... Такую SP лучше делать с указанием WITH RECOMPILE А реально эффективнее в большинстве случаев запуска этой SP будет все же, если внутри строить динамический запрос и выполнять через EXEC или sp_executesql, так как каждый раз будет выбран самый эффективный план запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 12:35:32 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
To Hi: What's up all? ("свистать всех наверх?") :) >>Как можно обойти использование sqlexec т.е. запустить хп не запуская? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 12:37:32 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
2Dankov Нужно избегать использовать sp_executesql - придётся давать права на таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 12:59:34 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
2 Dankov & alexeyvg В точку!!! (впрочем как всегда :) Мне нельзя давать прав на чтение таблиц, весь интерфейс только через SP. И в этом случае насколько я понял можно только так: where (a=@a or @a is null) and (b=@b or @b is null)... НО Смущает: >>Такую SP лучше делать с указанием WITH RECOMPILE Именно эти таблицы предполагаются "объемными" почему подобный подход заведомо не эффективен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 13:35:27 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
Потому что для конструкции (a=@a or @a is null) вряд ли будет использован индекс на поле "a", если таковой есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 13:56:37 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
2 Dankov Это полохо :( Очень полохо :( А WITH RECOMPILE чем поможет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 14:25:31 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
Точнее, может помочь. Если от значения параметров весьма зависит алгоритм, то лучше будет, если план будет строиться кажный раз заново. А этот случай именно такой. Поэтому и RECOMPILE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 14:38:11 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
К сожалению, в конструкции (a=@a or @a is null) and (b=@b or @b is null) будет использован индекс по "a" Причём with recompile не помогает :-( И скорость (и к-во чтений страниц) получается в 100000 (сто тысяч) раз хуже, чем при разделении запросов Это на небольшой таблице (1.5 млн записей) Может, конечно, при проверке были какие-нибуть случайности, типа неправильной статистики... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 15:43:32 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
Я обычно поступаю примерно так: 1. Пишу процедуру поиска по 1 параметру (желательно в индексированном поле) 2. Получаю рекордсет 3. К рекордсету применяю дополнительные фильтры 4. Вывожу результат Все работает очень шустро ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 15:53:00 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
2 alexeyvg >>И скорость ..получается в 100000 раз хуже, чем при разделении запросов т.е запросы можно разделить ? КАК? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 16:35:48 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
Где-то тут видел такой вариант: Код: plaintext Понятно, что в базе не нулл и можно подобрать фиктивное значение для параметра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 17:08:28 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
два варианта Код: plaintext 1. 2. Код: plaintext попробуй оба, сообщи результаты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2002, 18:41:21 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
2Hi Я имел в виду - по сравнению с двумя раздельными запросами: where a=@a и where b=@b Кстати, мне пришла в голову мысль - самое эффективное сделать union: select... from... where a=@a union select... from... where b=@b ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2002, 11:21:57 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
Спасибо всем за участие :) "Истина где-то рядом.." попробую объяснить всю ситуацию :-Р. У меня есть 4 таблицы, по сути фича для обмена MSG и все что надо это обычный ФИЛЬТР: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Все ID есно PRIMARY, CLUSTERED Как я уже сказал требуется обыкновенный фильтр. Task.TaskPriority, Task.TaskSendDate, Task.TaskReadDate, Inbox.UserID, Inbox.ReadDate и т.д. - Использование динамического запроса исключенно (доступ к таблицам закрыт). - Понятно что если передаваемый параметр null, то требуются все записи для по соответствующему полю, т.е. что-то вроде where @a = ISNULL(@a,0) не подходит, поскольку если NULL то ну ANY что ли :) здесь наверное можно подменить только даты с -> ISNULL(@ReadDate, '01/01/1700') или по -> ISNULL(@ReadDate, getdate()) А что с INT делать ? - ну и последнее. Все должно начинаться в Outbox т.к там собственно храняться доступные для фильтрации MSG TaskID 2 alexeyvg >>самое эффективное сделать union: Может я не понял идеи. но помоему union вернет "объединение". а мне то как раз требуется "пересечение" по всем условиям. Или у вас была другая идея? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2002, 12:42:44 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
Что-то не совсем понятно, что надо! Ты бы написал SELECT-ы с вариантами условий, как если бы ты делал через динамик и написал по русски, какие условия должны быть. Тогда, возможно, кто-нибудь тебе и поможет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2002, 14:17:48 |
|
||
|
Поиск в SP
|
|||
|---|---|---|---|
|
#18+
Возможно вы правы. В этом запросе я попытался использовать советы Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Как я понял здесь будет использован только индекс по OutBox.UserID, а InBox.UserID будет опущен. Это будет очевидный провал в поизводительности, поскольку MSG может быть групповым(нескольким UserID) поэтому в Inbox может быть до черта записей по одному TaskID ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2002, 15:26:22 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32049656&tid=1820395]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
43ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 338ms |

| 0 / 0 |
