Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Сравнение со списком значений. Как будет правильно?
|
|||
|---|---|---|---|
|
#18+
Недавно, роясь в нашем окаменелом дерьме исследуя наследие великих, обнаружил несколько скалярных функций вот такого типа: Код: 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. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. Я хотел уже переписать их так (по прежнему в скалярку, чтобы не ломать логику запросов, которые на них базируются): Код: 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. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. Но призадумался, а будет ли от этого польза и удовольствие? Т.е. будет ли оно меньше грузить диск, процессор, и вообще- работать быстрее? Можно ли, не глядя на план :-), сказать, что, например, второе - бест практиз, а первое - нет. Ну и наоборот. Ну или, может есть совсем правильное решение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2019, 18:23 |
|
||
|
Сравнение со списком значений. Как будет правильно?
|
|||
|---|---|---|---|
|
#18+
uaggsterЯ хотел уже переписать их так (по прежнему в скалярку, чтобы не ломать логику запросов, которые на них базируются) Но призадумался, а будет ли от этого польза и удовольствие? Т.е. будет ли оно меньше грузить диск, процессор, и вообще- работать быстрее?То есть переписать тело скалярки? ИМХО без разницы. PS Второй вариант выглядит подозрительно, с чего это серверу не выбрать из 2х записей "0" в запросе SELECT TOP 1 ? сортировки то нет, захочет, и выберет. Если бы оптимизатором был я, я бы вообще не выполнял часть с "from (values"; зачем, если возвращать всегда константу "0" будет по логике запроса безупречно правильно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2019, 22:13 |
|
||
|
Сравнение со списком значений. Как будет правильно?
|
|||
|---|---|---|---|
|
#18+
uaggsterНу или, может есть совсем правильное решение?А вообще, лучше такое хранить в словаре, а не в коде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2019, 22:16 |
|
||
|
Сравнение со списком значений. Как будет правильно?
|
|||
|---|---|---|---|
|
#18+
alexeyvg, Эээ... Union All выполняется последовательно, как except или intersect. Т.е. к первому резалтсету всегда приклеивается второй и т.д. Вот если б там union был, то точно б вернулся хаотически, т.к. он выполняется параллельно. Вроде так. Хотя, наверное, для полной уверенности можно добавить order by 1 desc. А по поводу "в словаре" - это не моя компетенция. Почему разработчики не вынесли это в табличку - я не знаю. Хотя по pattern всё равно ведь индекс не построишь. Построишь, но он всё равно сканироваться будет, не так ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2019, 22:32 |
|
||
|
Сравнение со списком значений. Как будет правильно?
|
|||
|---|---|---|---|
|
#18+
uaggsterХотя, наверное, для полной уверенности можно добавить order by 1 desc.Ага, это гарантирует, а "к первому резалтсету всегда приклеивается второй и т.д." - только предположения. uaggsterХотя по pattern всё равно ведь индекс не построишь. Построишь, но он всё равно сканироваться будет, не так ли?Я тут имел в виду администрирование всем этим хозяйством. Лучше словари хранить в справочниках, а не в коде, удобнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2019, 23:10 |
|
||
|
Сравнение со списком значений. Как будет правильно?
|
|||
|---|---|---|---|
|
#18+
Да, alexeyvg, вы абсолютно правы. Это не документированно, и лишь особенность оптимизатора: https://sqlperformance.com/2017/05/sql-plan/union-all-optimization Впрочем, в жизни б я все равно написал order by, просто потому, что испытывал бы чувство тревоги от потенциальной неоднозначности. :) Но это частности. Почему с with то нельзя писать? Мне заявляют - "я художник, я так вижу". Как парировать то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2019, 23:42 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39849516&tid=1687408]: |
0ms |
get settings: |
9ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
175ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
| others: | 247ms |
| total: | 527ms |

| 0 / 0 |
