|
чудеса при строковой аггрегации, если сдобрить функцией и посыпать сортировкой
|
|||
---|---|---|---|
#18+
Всем доброго времени суток. Это не ХЕЛПМИ!!!, но просто интересный случай, который я постичь не смог. @@version: Код: sql 1. 2. 3. 4.
Код: 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.
А теперь пытаемся собрать строку (в оригинале громоздкий Expression, я подобрал упрощенный, с теми же симптомами). Код: 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.
Результат: только последняя запись (нет аггрегации) А теперь делаем: - либо раскомментируем строку с ,@reply2+= - либо закомментируем sbor_type в сортировке - либо выбираем с top(1000) - либо в @reply += [dbo].myFunc([myId],[myId]) вместо первого из параметров myId передаем что угодно: 1, 'qq', 'qq'+str([myId]), sbor_type...... - и даже либо собираем и @reply, и @reply2 оба как += [dbo].myFunc([myId],[myId]) Результат: есть аггрегация. А теперь вернем все как было, и уже вместо второго параметра myId передаем 'qq'+ str([myId])) Результат: нет аггрегации . А теперь к такой первой строке раскомментируем второю и играемся. - , @reply2 += [dbo].myFunc(sbor_type,[myId]) - нет аггрегации - , @reply2 += [dbo].myFunc([myId],[myId]) - нет аггрегации - , @reply2 += [dbo].myFunc([myId],sbor_type) - есть аггрегация План "хороших" выборок: сначала Sort, потом Compute Scalar ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2020, 23:11 |
|
чудеса при строковой аггрегации, если сдобрить функцией и посыпать сортировкой
|
|||
---|---|---|---|
#18+
Виноват, не та фотка. Вот хороший план ) сначала Sort, потом Compute Scalar ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2020, 23:16 |
|
чудеса при строковой аггрегации, если сдобрить функцией и посыпать сортировкой
|
|||
---|---|---|---|
#18+
А вот "плохой" - где аггрегации не добились - в нем Compute Scalar вылезло вперед ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2020, 23:19 |
|
чудеса при строковой аггрегации, если сдобрить функцией и посыпать сортировкой
|
|||
---|---|---|---|
#18+
В общем, плохо понимаемое поведение, почему меняется порядок блоков, и почему это влияет на наличие/отсутствие суммирования строк, и как всем этим управлять, чтобы не получать сюрпризов. Что в итоге сделали: убрали сортировку по sbor_type. Оказалось допустимо. Но если бы она была жестко нужна (в оригинале sbor_type входит в Expression) - то тупик.... Пользуясь случаем, передаю всем привет, желаю крепкого здоровья, ну и ссылка тут в FAQ битая на майкрософт, там где !NB: https://www.sql.ru/faq/faq_topic.aspx?fid=130 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2020, 23:28 |
|
чудеса при строковой аггрегации, если сдобрить функцией и посыпать сортировкой
|
|||
---|---|---|---|
#18+
Как сочетаются "Microsoft SQL Server 2016" и "CREATE or alter"? Зачем здесь эта смешная функция? Что будет, если применить какой-нибудь другой способ клеить строки (коими FAQ несколько исписан)? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2020, 23:37 |
|
чудеса при строковой аггрегации, если сдобрить функцией и посыпать сортировкой
|
|||
---|---|---|---|
#18+
Это тысячелетний баян - https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/287515 ... Оптимизатор волен размещать Compute Scalar там, где сочтет правильным. И никакой агрегации на самом деле нет. А есть побочный эффект документированного поведения https://docs.microsoft.com/ru-ru/sql/t-sql/language-elements/select-local-variable-transact-sql?view=sql-server-ver15 SELECT @local_variable обычно используется для возвращения одиночного значения в переменную. Однако, если аргумент expression является именем столбца, может вернуться несколько значений. Если инструкция SELECT возвращает более одного значения, переменной присваивается последнее возвращенное значение. Сформулировано слегка неверно. На самом деле должно быть так - если инструкция SELECT возвращает более одного значения, переменной последовательно присваиваются значения из каждой возвращаемой строки. Именно на этом эффекте основана такая "агрегация" и именно поэтому она не работает, когда правая часть выражения вычисляется вне SELECT. До 2017-го сервера агрегировать строки с гарантированным результатом нужно через for xml path. Или написав CLR-агрегат Ну или можете поизвращаться Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2020, 23:52 |
|
чудеса при строковой аггрегации, если сдобрить функцией и посыпать сортировкой
|
|||
---|---|---|---|
#18+
Спасибо за отклики. >> Как сочетаются "Microsoft SQL Server 2016" и "CREATE or alter"? В целом, идиллически. >> Зачем здесь эта смешная функция? На ее месте могла быть не смешная. Она здесь затем, что симптомы прослеживаются при использовании udf. Из уважения к почтенной публике, не стал выкладывать оригинал - подобрал замену попроще. >> Что будет, если применить какой-нибудь другой способ клеить строки (коими FAQ несколько исписан)? Безусловно, можно подобрать рабочий вариант. FOR XML, или с выгрузкой в #промежуточную. Я не ставил это под сомнение. Если мы говорим о минимизации рисков, то от приведенного мной метода склейки надо сразу отказываться. Но тем не менее, старый код такой попадается, и разобраться - где та грань, когда подобный код из рабочего становится не рабочим - тоже любопытно. Чем-то же должно объясняться (помимо "именно поэтому!"), то, что не склеивает: select @reply += [dbo].myFunc([myId],[myId]) но склеивает оно же, написанное дважды: select @reply += [dbo].myFunc([myId],[myId]) , @reply2 += [dbo].myFunc([myId],[myId]) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 00:31 |
|
чудеса при строковой аггрегации, если сдобрить функцией и посыпать сортировкой
|
|||
---|---|---|---|
#18+
б-сВ целом, идиллически.Правильно, оказывается, писать "В целом, идиллически [начиная с 2016 SP1]". б-сЧем-то же должно объясняться (помимо "именно поэтому!")Объясняется тем, что "и не должно было, а там где работало как хочется, выходила чистая случайность". ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 01:22 |
|
|
start [/forum/topic.php?fid=46&msg=39997499&tid=1685668]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 154ms |
0 / 0 |