|
|
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
Необходимо для каждой записи исходного набора указать количество уникальных id, у которых сумма SM накопительным итогом > 0. Запрос ниже дает верный результат, но может есть вариант проще, короче (искомый результат - id_count). Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Например для записи с rn = 5 видим, что на этот момент у нас накоп. итог sm для id = 1 будет равен 100, накоп. итог для id = 2 будет равен 250. Итого для записи с rn = 5 id_count будет равен 2 (2 id с накоп. суммой > 0). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2018, 22:57 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
JDS, Ваш запрос правильно работает? почему для ід8 = 0? ps задачка наверняка для match_recognize ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 08:55 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
Stax, для rn=8 id_count=0, т.к. сумма с накоплением по id=1 и id=2 вышла в ноль к этой записи с rn=8, т.е. не осталось id с положительным остатком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 09:33 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
JDS, пока я пойму что надо, наверняка сотни решений предложат where t1.rn >= t2.rn как-бы намекает на start_of_group ps непонима Например для записи с rn = 8 видим, что на этот момент у нас накоп. итог sm для id = 1 будет равен 0, накоп. итог для id = 2 будет равен 50. Итого для записи с rn = 8 id_count будет равен 1 (1 id с накоп. суммой > 0). ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 09:52 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
Stax, точно. Будет 1 (в пятой строке после вставки вместо 100 изменил на 150) Значит все верно поняли ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 10:03 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
JDS, я так понимаю надо сэмитировать count( distinct (case when sm_over>0 then id end)) over (order by rn) ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 11:18 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
Stax, именно так ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 11:30 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
JDSStax, именно так ) імхо, надо спецов по match_recognize Ваш вариант в другой форме записи Код: plsql 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. идей пока нет, задачка навернака стандартная, мож чего нагуглю ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 11:50 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
JDS, если ид мало (varchar2(4000)) вот такой уродец для примера Код: plsql 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. ID_COUNT можно считать по запятых в LIST_ID, но уже набрал и жалко было выбрасывать .... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 15:12 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
Stax ID_COUNT можно считать по запятых в LIST_ID, но уже набрал и жалко было выбрасывать .... stax схалявил ,case when sm>0 then ','||id||',' else ' , ' end list_id ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 15:16 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
Тестить лень. Код: plsql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 15:57 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, імхо, должно работать (переход с -,0 на + и наоборот) ps sm + nvl(sum(sm) over(partition by id order by rn rows between unbounded preceding and 1 preceding),0) == sum(sm) over(partition by id order by rn) ? ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 16:29 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
Staxsm + nvl(sum(sm) over(partition by id order by rn rows between unbounded preceding and 1 preceding),0) == sum(sm) over(partition by id order by rn) ? Как бы да, но спецификация окна отличается - а так я даю оракелю шанс не считать окно дважды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 16:32 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousStaxsm + nvl(sum(sm) over(partition by id order by rn rows between unbounded preceding and 1 preceding),0) == sum(sm) over(partition by id order by rn) ? Как бы да, но спецификация окна отличается - а так я даю оракелю шанс не считать окно дважды. спасибо, понятно думаете будет over считать раз, я сильно сомневаюсь хотя на будущее, мож и так ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 16:36 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
Staxдумаете будет over считать раз, я сильно сомневаюсь Вообще Вы правы, ему по барабану - в конкретном случае считает один раз для окон unbounded preceding-current и unbounded preceding - 1 preceding (по крайней мере, 12с), можно самовыражаться яснее. Ну и если включить мозг, то можно и подсократить код: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 16:44 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousНу и если включить мозг, то можно и подсократить код: ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 16:58 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
Staxзадачка наверняка для match_recognizeИмеется в виду отметить выход в плюс и обнуление как сделал Андрей? Тут загвоздка в том, что все строки должны быть заматчены ибо агрегат, используемый в define clause, вычисляется в рамках каждого match. Код: plsql 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. В подобных выкрутасах особого смысла нет ввиду тривиальности решения с аналитикой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2018, 22:16 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
Спасибо всем, отличное решение. match_recognize надо бы отдельно изучать, но он начиная с 12-го работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2018, 02:06 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop В подобных выкрутасах особого смысла нет ввиду тривиальности решения с аналитикой. спасибо для меня решение стало тривильным после andrey_anonymous, хотя я изначально 1 preceding рассматривал, не додул что надо в разрезе partition by id match_recognize пригодится как пример ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2018, 08:37 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, вопрос не дописал для суммирования +-, я так понимаю, из-за partition by id надо в подзапрос, или можно извратится? ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2018, 09:39 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
Staxmatch_recognize пригодится как примерБыло недавно аналогичное Можно ли аналитикой? . Там match_recognize более уместно (ты там тоже участвовал). Staxдля суммирования +-, я так понимаю, из-за partition by id надо в подзапрос, или можно извратится?Я не вижу варианта без подзапроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2018, 11:07 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopStaxдля суммирования +-, я так понимаю, из-за partition by id надо в подзапрос, или можно извратится?Я не вижу варианта без подзапроса.Точнее подзапрос там не нужен, аналитика просто добавляется в select-list. Но все равно это двухходовочка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2018, 11:13 |
|
||
|
Переписать запрос. Количество уникальных значений с накоплением.
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopdbms_photoshopпропущено... Я не вижу варианта без подзапроса.Точнее подзапрос там не нужен, аналитика просто добавляется в select-list. Но все равно это двухходовочка. понятно питался в measures "просуммировать" ps імхо двухходовочка, но без подзапросов .... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2018, 11:40 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39634522&tid=1884111]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
69ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
77ms |
get tp. blocked users: |
2ms |
| others: | 228ms |
| total: | 429ms |

| 0 / 0 |
