|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
А на клиенте соответсвенно: Код: vbnet 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 20:39 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Так это ж опять динамика. Что тебе мешает создать статическую вьюшку, я никак не могу понять. Зачем ее каждый раз создавать и удалять? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 20:43 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Palarm Код: sql 1. 2.
небольшое замечание по ходу дела: ты постоянно оперируешь между varchar и nvarchar-строками, то есть заставляешь сервер постоянно преобразовывать один тип данных в другой, правильно так: Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 20:50 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Shocker.ProТак это ж опять динамика. Что тебе мешает создать статическую вьюшку, я никак не могу понять. Зачем ее каждый раз создавать и удалять?Видимо долгое юзание Аксес в качестве СУБД сформировало порочные с позиции T-SQL автоматизмы мышления: динамические запросы, обработка данных на клиенте, процедурное программирование и т. д. - БД по сути использовалось как мешок для мусора, в котором надо ковыряться из клиента. В итоге со скрипом въезжаю в то, что для тебя банальности. PS: тут да, конечно пишем статичную вьюху - кавычки в топку ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2015, 03:48 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7.
При таком коде не будет лишних тормозов при пробежке по If-ам, которых может быть сотни? Тут как бы просится ELSEIF которого нет в T-SQL или может здесь при нахождении нужного условия дальнейший поиск прекращается? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 19:54 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Shocker.ProДинамика компилируется каждый раз при вызове, каждый раз производится анализ таблиц и составляется план запроса. Не динамический запрос компилируется сразу, план составляется тоже сразу. Излишне говорить, что это влияет на производительность.Я так понимаю, что запуск селекта через ADO имеет тот же негатив? То есть con.Execute(...) выполняется медленнее чем запуск хранимки через тот же con.Execute? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 19:57 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
PalarmПри таком коде не будет лишних тормозов при пробежке по If-ам, которых может быть сотни? Тут как бы просится ELSEIF которого нет в T-SQL или может здесь при нахождении нужного условия дальнейший поиск прекращается?Что мешает использовать else? elseif всего лишь удобная форма для записи цепочки if-ов. А вообще, правильнее под каждый селект создавать отдельную хранимку, а не пытаться запихать всю логику всего приложения в одну. Это, кстати, поможет оптимизатору SQL. Понимаю, что снова мешает менталитет программиста динамических запросов на клиенте, но, как я уже говорил, надо менять взгляды. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2015, 14:01 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
PalarmЯ так понимаю, что запуск селекта через ADO имеет тот же негатив? То есть con.Execute(...) выполняется медленнее чем запуск хранимки через тот же con.Execute?совершенно верно. Select - это тот же динамический запрос. Как я уже говорил выше - клиента нужно писать так, чтобы он понятия не имел про язык SQL. Он просто вызывает хранимку с определенными параметрами и получает ответ в определенном формате. Нет ничего страшного, что на сервере будет тысяча хранимок. Тебе же не мешает та же самая тысяча процедур/функций на клиенте. Так и воспринимай - хранимка, это процедура/функция, которая выполняется на сервере, а не на клиенте. И если функция на клиенте или хранимка на сервере содержит всего одну строку - в этом нет ничего страшного. Данный подход имеет и побочный эффект: можно модернизировать хранилище, не переписывая клиента и/или сохранять совместимость со старыми версиями. Это особенно удобно, если клиентов много и взять и резко обновить всем версию клиента представляется затруднительным. Просто в новой версии обращаешься к тем же данным по-новому (новая хранимка или новые параметры хранимки, имеющие значения по умолчанию), старые клиенты продолжают работать по-старому ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2015, 14:08 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Shocker.ProА вообще, правильнее под каждый селект создавать отдельную хранимку, а не пытаться запихать всю логику всего приложения в одну. Это, кстати, поможет оптимизатору SQL. Понимаю, что снова мешает менталитет программиста динамических запросов на клиенте, но, как я уже говорил, надо менять взгляды. Хочешь сказать, что вот так хранимку для списка писать не кошерно, с позиwии T-SQL Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41.
Я тут начал изворачиваться через комбинации параметров, чтобы через одну вьюху и хранимку создать источники для нескольких списков, использующих одну таблицу, но с разными фильтрами. А по твоим рассуждениям надо каждому списку свою хранимку - чтобы получить максимальную скорость. Ну допустим. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2015, 20:19 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Натыкался еще на такой способ "уменьшения кол-во объектов на сервере" - использование .NextRecordset. То есть пишется хранимка с несколькими селектами, а спискам в той же последовательности присваиваются через .NextRecordset источники. Понятно, что опять рефлексия минимизации - а скорость будет такая же как при отдельных хранимках или ниже? Shocker.ProДанный подход имеет и побочный эффект: можно модернизировать хранилище, не переписывая клиента и/или сохранять совместимость со старыми версиями. Это особенно удобно, если клиентов много и взять и резко обновить всем версию клиента представляется затруднительным. Просто в новой версии обращаешься к тем же данным по-новому (новая хранимка или новые параметры хранимки, имеющие значения по умолчанию), старые клиенты продолжают работать по-старомуМне твой совет по переносу всех селектов на сервер толкнул еще одну мысль - проще будет сменить платформу клиента. Не век же на Аксесе лабать. + возможность развернуть целую сетку клиентских приложений на смартфонах, планшетах и т. п. юзающих одну БД + возможность параллельной разработки БД и клиента, как в web: дизайнер + программист. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2015, 20:27 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Palarm Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
просто, если немножко подумать, то: Код: sql 1. 2. 3. 4. 5.
что касается [NOT] IN - то тут делается инлайн-функция для повторяющегося кода, а where и order остаютс в процедуре, но тот всего два варианта ведь, а не сотня ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2015, 20:40 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
PalarmНатыкался еще на такой способ "уменьшения кол-во объектов на сервере" - использование .NextRecordset. То есть пишется хранимка с несколькими селектами, а спискам в той же последовательности присваиваются через .NextRecordset источники. Понятно, что опять рефлексия минимизации - а скорость будет такая же как при отдельных хранимках или ниже?тут, в общем-то, идет минимизация обращений к серверу. То есть используя возврат нескольких рекордсетов ты экономишь на накладных расходах установки соединения и отсылке запроса к серверу. При медленном соединении и интенсивных запросах на этом можно сэкономить. Но у меня, к примеру, в проекте с полутора тысячью хранимок этот прием используется дай бог в десятке. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2015, 20:44 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Palarmпроще будет сменить платформу клиента. Не век же на Аксесе лабать. + возможность развернуть целую сетку клиентских приложений на смартфонах, планшетах и т. п. юзающих одну БД + возможность параллельной разработки БД и клиента, как в web: дизайнер + программист.Тогда во-первых смотри на трехзвенную архитектуру: СУБД, сервер приложения и клиент. При этом клиент в таком случае не то что об SQL, вообще о БД не имеет никакого понятия. Он обращается к серверу приложений за высокоуровневыми функциями. Но тут уже смотри... Последнее время есть тенденция использовать ORM. Это означает в основном отказ от языка SQL. Тут свои достоинства и недостатки, споров много, в основном переход на ORM считается прогрессивным. Я одно приложение наваял не очень нагруженное - да - удобно, но надо опять сильно перестраивать мозг. Вообще, выбор платформы, это тема бесконечной дискуссии )) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2015, 21:00 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Спасибо за помощь :) Еще вопрос: есть много таких блоков Код: vbnet 1. 2. 3. 4. 5. 6. 7.
тут видится 2 варианта: 1. сделать udf возвращающей bit и в зависимости от него запускать мессагу (но опять же - как гвоздем по стеклу - лепить кучи одностроковых функций - эх) 2. вставить проверку в хранимку - делать прерывание - отсылать клиенту код - ждать ответа - продолжать или закрывать выполнение. Но тут походу кощунство для T-SQL адептов - попытка внедрить процедурное мышление :) Да и навряд ли T-SQL поддерживает такие пинг-понги с клиентом, по крайней мере я не встречал примеров. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2015, 08:40 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Во-первых, открой для себя Exists, это будет быстрее, чем Count>0 Во-вторых, проблему диалога с пользователем я лично для себя решил следующим образом. Дано - хранимка может выполнить задачу, либо вернуть ошибку, либо вернуть запрос на подтверждение пользователем продолжения работы хранимки (таких запросов может быть N). Хранимка возвращает >=0 при успешном выполнении, -1, если ошибка без возможности продолжения, -2 запрос к пользователю на возможность продолжения. Поскольку подтверждений может быть несколько, ответ циклически накапливается в Confirm, текст ошибки или подтверждения в ErrMsg. В хранимке: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
то есть в @Confirms$ накапливаются подтверждения пользователя типа N'MYKEY1$N'DELETE$EMPTYNAME$' и т.п. по количеству проверок. на клиенте Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
или Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2015, 11:49 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Стало быть повторный вызов с обновленным параметром, причем если через return то придется запускать через cmd.Parameters.Append cmd.CreateParameter("RETURN_VALUE", adInteger, adParamReturnValue). А если как мне больше нравится через con - тогда свой Output параметр туда вводить. Спасибо за наводку. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2015, 13:39 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
PalarmСтало быть повторный вызовда. Ведь надо понимать, что пользователь может думать час над мессаджбоксом, за это время в базе может много чего измениться. То есть все проверки каждый раз проводятся заново - во избежание... ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2015, 13:50 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Наваял, работает, причем всем назло через con.Execute, а не cmd.Parameters :) Было: Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37.
Стало Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.
И на серваке Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2015, 15:22 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Код: vbnet 1.
Предполагаю, что аналога именно такого прерывания нет в T-SQL, а нужно делать как в вышеприведеных примерах - отсылать клиенту код ошибки и там уже принимать решение - перезапускать выполнение хранимки или нет. Правильно? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2015, 11:14 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
PalarmПредполагаю, что аналога именно такого прерывания нет в T-SQLчем не нравится return? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2015, 11:23 |
|
Результат хранимки через ADO
|
|||
---|---|---|---|
#18+
Вообще то да. Тогда еще вопрос: есть ли возможность организовать индикацию процесса выполнения хранимки? Имеется в виду отдельная форма с бегунком. Тут ведь по любому придется делать множество перезапусков хранимки, чтобы вернуть текущее состояние процесса и отразить его для пользователя. Оно понятно, что на сервере надо стараться работать с блоками данных, а не циклами, и по большому счету от бегунка кроме лишних тормозов толку особого нет - но из любопытства: может есть какой progressbar в T-sql или какой то маневр, чтобы его запустить на клиенте? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2015, 11:44 |
|
|
start [/forum/topic.php?fid=60&msg=39115449&tid=2155711]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 135ms |
0 / 0 |