Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
Добрый день. Есть запрос, который работает хорошо и вариантов которого можно представить несколько, но никак не пойму, как сделать его пригодным для того, чтобы на его основе создать индексированное представление. To нельзя использовать Min/Max, то получается SelfJoin, то еще чего-то. Подтолкните, пожалуйста, к верному решению. Таблицы: SKUsEvents (SKUsEventID, EventDate, SKUsEventsTypeID, ....) - таблица событий, описывает дату события, тип и другие параметры. SKUsEventsSKUs - (SKUsEventID, SKU, Quan) указывает, какие конкретно товарные позиции были в данном событии, с указанием количества. SKUsCapsulesTrans - (SKU1, SKU2, ResultSKU) - используется только для определенного типа событий, как раз из-за которого эта вьюха и нужна (сборка, когда точно известно, что из двух конкретных SKU получается один конкретный третий). SKU2 всего больше SKU1. Таким образом, для всех событий с SKUsEventsTypeID = 11 в таблице SKUsEventsSKUs всегда ТОЛЬКО ДВЕ строки, из которых можно понять, что конкретно взяли для сборки. Задача - получить вьюху "готовых" продуктов. Решение 1: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Решение 2 (без агрегатов, но с SelfJoin): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Есть мысль переделать SKUsCapsulesTrans в структуру вида (SKUSource, SKUResult, VariantID), где последняя колонка будет служить для группировки по "правильным сочетаниям", но тут тоже не уверен, что сразу все получится.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2019, 18:35 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
Если SKUsCapsulesTrans переделать в такой вид (SKUSource, SKUResult, VariantID), то получится такой запрос. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Но HAVING тоже нельзя((( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2019, 18:50 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
Еще один вариант - это разнести на два события с одинаковой датой: первое будет ввод (с двумя SKU), второе - вывод - с одним. Это тогда решит все проблемы с индексированной вьюхой, но будет избыточность и как-то не очень красиво это. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2019, 19:04 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
Alexey30, без наборов данных непонятно - что на входе и что надо получить на выходе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 11:14 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#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. На выходе получаем Код: sql 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 11:54 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
если так уж хочется имитировать индексированное представление, сами храните и поддерживайте в отдельной таблице свои MIN(SKU), MAX(SKU). сервер это не делает по простой причине: если в вашей таблицы проайпэйтит строку, то пересчитывать COUNT_BIG(*) ему не надо: счетчик просто не изменится (при вставке строки увеличится, при удалении уменьшится) а как, простите, пересчитать MIN и MAX, не сканируя всю таблицу? может, вы как раз своим апдэйтом истребили предыдущий MIN/MAX? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 12:13 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
Alexey30, от сортировка Вы никуда не уйдёте. Для быстрой выборки вам надо создать витрину, которая будет обновлять min/max при изменениях исходных таблиц. Всегда жертвуешь или скоростью или объёмом хранения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 13:45 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
Alexey30, Просто разделите ваш запрос на 2 представления. В одном, индексированном, храните исходные данные, а второе, с группировками, мин и макс - сделайте обычным. Ну, т.е. если весь запрос нельзя сделать индексированным представлением, сделайте максимально возможную заготовку, и обычное представление, его использующее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 14:40 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
uaggsterAlexey30, Просто разделите ваш запрос на 2 представления. В одном, индексированном, храните исходные данные, а второе, с группировками, мин и макс - сделайте обычным. Ну, т.е. если весь запрос нельзя сделать индексированным представлением, сделайте максимально возможную заготовку, и обычное представление, его использующее. смысл сего действа в чем? индексированное представление не пересчитывает агрегаты типа count() при обновлении таблиц. а если их все равно придется пересчитывать в вашем "просто представлении" (скан + сорт), то зачем весь этот огород? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 15:19 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
Yasha123uaggsterAlexey30, Просто разделите ваш запрос на 2 представления. В одном, индексированном, храните исходные данные, а второе, с группировками, мин и макс - сделайте обычным. Ну, т.е. если весь запрос нельзя сделать индексированным представлением, сделайте максимально возможную заготовку, и обычное представление, его использующее. смысл сего действа в чем? индексированное представление не пересчитывает агрегаты типа count() при обновлении таблиц. а если их все равно придется пересчитывать в вашем "просто представлении" (скан + сорт), то зачем весь этот огород? Ну сузить же набор данных, с которым работает запрос, который потом считает min, max и count. И построить по этому набору кастомные индексы, если их напрямую нельзя по каким-то причинам построить по исходным таблицам. Для чего еще indexed view нужны? Нет, я понимаю, что может быть, в данном конкретном случае этот совет сродни "мыши, станьте ежиками". Но, вообще - нормально это работает. Вырезать из звездообразного соединения те поля, которые нужны, отсечь, например, началом года, и построить индексы по полям, которые в родных таблицах в качестве индексируемых - не фигурируют. Чем плохо то? Даже по вертикально суженной выборке - агрегаты будут быстрее считаться, в отличие от исходных "широких таблиц". И потом, columnstore можно и поверх индексированного представления создать http://www.nikoport.com/2016/10/10/columnstore-indexes-part-87-indexed-views/ (не пробовал, кстати). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 16:38 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
Alexey30Если SKUsCapsulesTrans переделать в такой вид (SKUSource, SKUResult, VariantID)Можете так извратиться: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 16:41 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
uaggsterДаже по вертикально суженной выборке - агрегаты будут быстрее считаться, в отличие от исходных "широких таблиц". И потом, columnstore можно и поверх индексированного представления создать так columnstore и без вью можно создать. и считать агрегаты быстрее. --- у него же нет там никакой кучи соединений, у него считаются 2 агрегата, по которым потом и фильтруется остальное. я и говорю: если эти мин и макс можно как-то посчитать отдельно, то самому и надо считать. например, тот же мин может не меняться вовсе, а макс -- только увеличиваться при вставке, а поле и вовсе необновляемое. вот тогда хранить их в таблице в 1 строку и самому обновлять ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 16:47 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
Yasha123uaggsterДаже по вертикально суженной выборке - агрегаты будут быстрее считаться, в отличие от исходных "широких таблиц". И потом, columnstore можно и поверх индексированного представления создать так columnstore и без вью можно создать. и считать агрегаты быстрее. Флейма для: Дык весь смысл вырезать из звездочки заготовку, и уже по ней построить колумнстор. Эдакое эрзац - хранилище. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 17:04 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
uaggster, это называется "витрина". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 18:21 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
uaggster, а кск вы колумнсторы в 2014 Standard делаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 18:45 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
Огромное спасибо всем за уделенное время и внимание. Видимо, остановлюсь на варианте от invm. invm, отдельное спасибо :) И вопрос. Стоит ли включать столбец Quan в индекс, если по нему НЕ будет производиться выборка в будущем, он используется только внутри агрегата для подсчета остатков на момент времени? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 18:53 |
|
||
|
Переписать запрос для использования в индексированном представлении
|
|||
|---|---|---|---|
|
#18+
Alexey30Стоит ли включать столбец Quan в индекс, если по нему НЕ будет производиться выборка в будущем, он используется только внутри агрегата для подсчета остатков на момент времени?В данном случае в ключ индекса включены все столбцы из предложения group by для обеспечения его уникальности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2019, 20:05 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39840505&tid=1687501]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
73ms |
get tp. blocked users: |
2ms |
| others: | 260ms |
| total: | 421ms |

| 0 / 0 |
