|
|
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
есть необходимость: 1) пронумеровать записи на уровне группировки PRODUCT + trunc(TIME_ID) - это делает row_number() в примере ниже 2) затем для каждой строки, где row_number() = 1, получить на том же уровне группировки PRODUCT + trunc(TIME_ID) значение QUANT, которое существовало для первой по TIME_ID записи из последней по времени группы (непрерывной последовательности) записей с флагом "OPER" = D в примере ниже: записи #4 и 5 в дате 04.04.2001 по PRODUCT=can формируют последнюю по времени группу с флагом "OPER" = D первая из них - запись №5 соответственно, в строку 4 необходимо вывести значение из нее = 9 ВАЖНО: ниже указанной группы возможны еще записи с флагом "OPER" = D - в примере ниже это запись №7 - эти значения не интересуют, нужна строго последняя группа вопрос - как сделать это эффективно? задача массовая (миллионы строк), inline view не прокатит спасибо! Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 19:05 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Alexus12, start_of_group погугли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 19:14 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
На аналитике можно так: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Есть и другие варианты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2016, 21:30 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, спасибо! но есть проблема: если на уровне группировки PRODUCT + trunc(TIME_ID) существует только одна группа - получим неверное значение FV Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2016, 12:51 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Alexus12но есть проблема: если на уровне группировки PRODUCT + trunc(TIME_ID) существует только одна группа - получим неверное значение FV Ну так поправьте. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2016, 13:15 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2016, 18:43 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
на ASKTOM найден пример: group records by interval of 3 seconds https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:13946369553642 цитата: Код: 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. 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. по образу и подобию решена моя задача: Код: 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. 57. GROUP_NUMBER_DENSE вычислен "для красоты", для решения задачи он не требуется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2016, 18:45 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Alexus12, это вариация на тему обычного для нашего форума start_of_group, который Вам рекомендовали в первом ответе. На данном форуме было принято писать чуть иначе - маркировать переключение группы единичкой, и уровнем выше суммировать нарастающим итогом - на одну аналитическую функцию меньше, чем в Вашем решении. Решение типовое, но два inline view - from(from(from)) Ваша конкретная задача может быть аналитикой решена за from(from), это проще в сопровождении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2016, 18:53 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousэто проще в сопровождении.Проще типовое решение, а не опирающееся на некие закономерности данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2016, 19:02 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Elicandrey_anonymousэто проще в сопровождении.Проще типовое решение, а не опирающееся на некие закономерности данных. Будь оно типовым для ТС - он не задавал бы здесь этот вопрос :) Упрощение достигнуто не за счет закономерности данных, а за счет решения строго той задачи, которую поставил ТС - я использовал в качестве маркера группы целевое значение, что исключило необходимость в нумерации групп и проведения дополнительного сеанса аналитики с указанием нового окна, отличного от исходного. Вероятно, можно и еще упростить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2016, 19:30 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousВероятно, можно и еще упростить. Ну если не упростить, то поаккуратнее самовыразиться точно можно: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2016, 19:45 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, спасибо за решение "на одну функцию меньше" - оно однозначно заслуживает внимания мое решение (базированное на ответе Тома Кайта, выше) визуально и алгоритмически понятнее (не)квалифицированной поддержке, ваше может быть эффективнее в рантайме, будем сравнивать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 11:33 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
кстати, возможно ли решение через MODEL? мои познания в ней стремятся к 0, а здесь http://www.oracle.com/technetwork/issue-archive/2012/12-mar/o22asktom-1518271.html Кайт публикует результаты 3 вариантов решения одной задачи (bin fitting - разложить записи в корзинки, переходя к следующей корзине при заполнении предыдущей), базирующееся на обсуждении на asktom (ссылка в статье есть), где говорится, что MODEL оказался самым эффективным вариантом (на asktom приведена статистика) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 11:41 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Alexus12кстати, возможно ли решение через MODEL? Да, на model возможно. Возможно также на табличной функции, на скалярном подзапросе, recursive subquery factoring и даже на connect by. Эффективность зависит от реальных данных, наличия/отсутствия подходящих индексов и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 13:02 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
для решаемой задачи - миллионы строк на дату на входе, индексов нет соответственно, подзапросы, recursive subquery и т.п. подходы вне игры вариант pipelined-функции - как у Кайта в статье выше, который он предложил как свое решение для bin fitting - возможен какое ваше экспертное мнение - стоит ли пробовать, или запрос на аналитике будет более выигрышным, чем она? на каком месте по производительности может стоять вариант на MODEL (не знаю ограничений ее производительности - ткните носом плз)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 14:07 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
для oracle 12c возможен также вариант на MATCH_RECOGNIZE http://www.oracle.com/technetwork/issue-archive/2015/15-mar/o25asktom-2458830.html у меня 11.2, увы... ...но для него Кайт в той же статье приводит вариант - The MODEL clause solution to “Finding MIN/MAX Values”: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 14:31 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Alexus12вариант pipelined В означенных условиях (много данных, без индексов) имеет смысл использовать параллельное исполнение. Pipelined возможно, если можете позволить себе задекларировать ее как parallel_enabled (strong ref cursor, наличие ключа по которому делить). Надо учитывать, что у модели parallel execution от oracle есть два неприятных ограничение реализации, которые в случае pipelined проявляются нагляднее, а именно: - oracle не умеет ставить в конвейер более двух наборов параллельных серверов, поэтому если нужен третий набор - случится промежуточная буферизация результата. - oracle не умеет организовать порционную обработку, т.е. набор 1 встанет обслуживать шаг 3 только после полного завершения работы по шагу 1, поэтому буферизоваться будет ВЕСЬ датасет из второго набора параллельных серверов, пока не освободится первый набор для того, чтобы заняться третьим этапом. Понимаю, на слух сложно воспринимается. Попробуйте нарисовать. pipelined тут особенно заметна, поскольку ввиду синтаксических особенностей требуется сразу два набора серверов - первый работает над формированием входного курсора для pipelined (отбор данных и рассылка второму набору согласно спецификации parallel_enable), второй - собственно выполняет pipelined. Так вооот... Если делаем просто select - все в порядке. Но если пытаемся заслать датасет в следующий этап типа merge или insert - получаем промежуточную буферизацию всего набора данных. Большой набор в памяти не помещается и вываливается в TEMP, что приводит к катастрофическому падению производительности. Аналитика тоже может запросто привести к аналогичному результату - но тут надо смотреть предметно. Если удастся объяснить ораклу, что параллельные процессы не пересекаются по данным (получить combined with parent для 2 и третьего этапов), то буферизации может быть удастся избежать - а с pipelined точно не удастся ... По model - тема сложная. Слишком много вариантов у модельки - итеративная, sequential rules, референсные модели... Куча условностей, влияющих на порядок выполнения. По сути еще один движок, в плане сложности мало уступающий SQL-engine - при практически полном отсутствии исследований/публикаций на тему internals. Black Box. Я до сих пор в прод запустил только одну совсем простую модельку с единственным правилом - без нее было очень сложно решить конкретную задачу. ...по Вашей задаче - еще можно попробовать MATCH_RECOGNIZE. Вроде неплохо отрабатывала объемы на тестах - не хуже сортировки, по крайней мере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 14:34 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, спасибо за детальные пояснения по pipelined вариант на MODEL на основе примера Кайта выше: Код: 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. ухожу тестировать производительность на миллионах строк... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 16:18 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Моделька тоже позволяет partition by. Упрощает правила и позволяет серверу разделить работу на части. Ну и аналитика на выходе модельки - ИМХО не очень. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 16:25 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousМоделька тоже позволяет partition by Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 16:31 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
И first_value убрать Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 16:57 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, вероятно, нужно убрать строку f[ rn>1 ] = quant[cv()] - она корежит данные, без нее все верно... итоги серии замеров на моих объемах (7 млн строк): аналитика - ваш вариант = 6+ сек аналитика - мой вариант = 27+ сек model - ваш вариант = 28+ сек model - мой вариант = 57+ сек вывод - аналитика рулит, причем не типовое решение, а заточенное под конкретную задачу снимаю шляпу ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 18:31 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Alexus12вероятно, нужно убрать строку f[ rn>1 ] = quant[cv()] - она корежит данные, без нее все верно... Это очень странно, поскольку данное правило возвращает f значение quant для всех строк, которые "не первые". Иначе f содержит "первое значение из последней группы" для всех записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 19:39 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, если данная тема http://www.sql.ru/forum/1233510-a/vakansii-na-kontrol-kachestva-dannyh-moskva заинтересует , прошу сообщить по указанному в ней адресу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2016, 19:42 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Alexus12andrey_anonymous, итоги серии замеров на моих объемах (7 млн строк): аналитика - ваш вариант = 6+ сек аналитика - мой вариант = 27+ сек model - ваш вариант = 28+ сек model - мой вариант = 57+ сек вывод - аналитика рулит, причем не типовое решение, а заточенное под конкретную задачу снимаю шляпу ;) при дальнейшей разработке выяснился неприятный момент: lag(fv_ ignore nulls) плохо масштабируется - скорость обработки падает не пропорционально увеличению кол-ва строк на входе, а быстрее. у first_value такой проблемы нет - вариант из моей адаптации примера Кайта 19743456 показывает пропорциональный рост времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2016, 17:35 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousПо model - тема сложная. Слишком много вариантов у модельки - итеративная, sequential rules, референсные модели... Куча условностей, влияющих на порядок выполнения. По сути еще один движок, в плане сложности мало уступающий SQL-engine - при практически полном отсутствии исследований/публикаций на тему internals. Black Box. Я до сих пор в прод запустил только одну совсем простую модельку с единственным правилом - без нее было очень сложно решить конкретную задачу.Если не мешать все в кучу, то все достаточно тривиально. Прежде всего модель означает загрузку всего набора данных в PGA для последующих speadsheet-like calculations. При этом создается workarea c operation_type равным 'SPREADSHEET'. Если в модели присутствует аналитика/агрегаты, то ясное дело создаются дополнительные рабочие области для сортировки и прочего. Для обычной моедли правила вполняются столько раз сколько указано в rules. Как правило указано не более одного правила на одну меру. В случае итеративной выполнения правил соотвественно вся кухня выполняется n раз. Правила бывают разного типа (с точки зрения перфоманса тоже), не буду в это счас углубляться. "Условности" косвенно понимаются по плану {ORDERED [FAST] | ACYCLIC [FAST] | CYCLIC}. Референснсные модели не более чем "рюшечка" и в них никакой необходимости вообще нет имхо - можно разрулить дополнительным соединением при получении набора данных для модели. Главный жирный минус - нелинейный рост там, где recursive subquery factoring или PL/SQL solutions имеют линейный (я молчу про случаи когда workarea не влезает в опаративку и уходит в TEMP TS). Думаю я не очень много нового сообщил. :) Вообще работа почти написана, надеюсь в ближйший месяц опубликовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2016, 18:21 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
+ попробовали нагрузочный тест варианта через MODEL 19747142 - оказался в 3 раза быстрее варианта моей адаптации примера Кайта 19743456 и при этом линейно масштабируемым >Главный жирный минус - нелинейный рост там, где recursive subquery factoring или PL/SQL solutions имеют линейный (я молчу про случаи когда workarea не влезает в опаративку и уходит в TEMP TS). dbms_photoshop , можете ли привести примеры / скрипты, чтобы оценить, как этот вариант нагружает систему / когда вылезает в TEMP? вопрос важный, т.к. объемы большие (миллионы строк) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2016, 18:53 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Alexus12dbms_photoshop , можете ли привести примеры / скрипты, чтобы оценить, как этот вариант нагружает систему / когда вылезает в TEMP? вопрос важный, т.к. объемы большие (миллионы строк)Странный несколько вопрос. Я ж не знаю вашей конфигурации. Если есть желание, чтоб ушло в темп, можно сделать в сессии примерно следующее Код: plaintext 1. Нагрузочное тестирование тоже звучит несколько странно. Пока будет хватать оперативки и CPU для каждого из процессов все может быть относительно хорошо. А вот с ростом data volumes модель будет все больше уступать альтернативным решениям. Я не совсем согласен с выводами Кайта, как будет время посмотрю детальнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2016, 19:11 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, >А вот с ростом data volumes модель будет все больше уступать альтернативным решениям. вот про это и интерес - есть информация, когда это начинается / как узнать и измерить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2016, 19:49 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Alexus12dbms_photoshop, >А вот с ростом data volumes модель будет все больше уступать альтернативным решениям. вот про это и интерес - есть информация, когда это начинается / как узнать и измерить?Я сказал, что зависит от настроек. Я рассказал про инструментарий и как пользоваться (как узнать и измерить). Я объяснил некорректность вопроса. Ты продолжаешь задавать то же самое. Предполагается, что надо все прожевать и в рот положить? Тест ниже для демонстрации не масштабируемости для задачи Кайта. (мотивацией для нижеследующего было убедиться, что Кайт неправ) Код: 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. 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. Первые две итерации PL/SQL проигрывает в пределах погрешности. Потом модель проигрывает в три раза, потом в четыре, потом в пять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 01:45 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Еще пару моментов. 1) тестировать вариант с recursive subquery factoring для данной задачи без индекса на таблице - это вообще не серьезно, поэтому я его не включал. 2) если добавить к тесту выше еще одну итерацию (то есть на последней итерации будет 1М строк), результаты выглядят следующим образом. cnt - время выполнения в секундах число строк соответственно 10 000, 100 000 и 1 000 000. В последнем случае начинает уходить в темп для обоих подходов. PL/SQL выполнился за минуту, для модели после получаса выполнения прибил сессию. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 02:23 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, pattern matching Код: 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. Потому как если делать, чтоб был матч на каждую группу I/D то нельзя посчитать rn (она будет в рамках группы, а не всей секции). А если делать матч на всю секцию, то нельзя посчитать "первую запись из последней группы" (будет первая запись в рамках всей секции, а не последней группы). А поскольку в вашем решении во всех аналитических функциях одинаковое окно, то смысла в match_recognize нет. Ну разве что таки можно извратиться и достичь нужного одним match_recognize без аналитики... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 04:01 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 11:07 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopandrey_anonymous,...нельзя посчитать rn (она будет в рамках группы, а не всей секции). Если я ничего не путаю, то по постановке этого не требовалось. rn появился в экспериментах ТС как побочный эффект от sog. ...что касается sog, то вариант, многократно вылизанный на данном форуме, мне как-то больше по душе, чем вариант с asktom... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 15:33 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousrn появился в экспериментах ТС как побочный эффект от sog У него на это заточена логика. Alexus12затем для каждой строки, где row_number() = 1 ...Речь не про sog. Замечание было по поводу невозможности решения одним pattern matching и без аналитики. Если я неправ - просьба опровергнуть с помощью конкретного решения. Вот и всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 15:40 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
>затем для каждой строки, где row_number() = 1 мне нужна эта строка для дальнейшей обработки, да ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 15:45 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, слегка изменили ваш вариант отсюда 19743612 получилось так: Код: 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. изменения: 1) во внутреннем запросе в выражении case lead(oper, 1, oper) убран последний oper - поэтому для крайнего значения возвращается null, что приводит к выводу в fv_2 значения _в том числе_ для первой записи первой подгруппы, а не только при смене подгрупп 2) во внешнем : выражение case rn -- when 1 then -- coalesce( -- lag(fv_ ignore nulls) over(partition by PRODUCT, trunc(TIME_ID) order by TIME_ID) -- , first_value(quant) over(partition by PRODUCT, trunc(TIME_ID) order by TIME_ID) заменено на , last_value(fv_2 ignore nulls) over (partition by PRODUCT, trunc(TIME_ID) order by TIME_ID ) lv это протягивает найденные во внутреннем запросе значения fv_2 от первой записи подгруппы на все ее записи в результате код избавился от тормозов, вносимых lag(fv_ ignore nulls) , и масштабируется линейно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 15:56 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopОдним только 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. В решении предполагается, что последняя группа состоит из D. Если это может быть не так - то просто чуть усложняется шаблон. Как выяснилось case/decode в measures всегда возвращают null. Еще баг из той же оперы: 20561938 . Но там one row per match и криво работает nullif. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2017, 22:31 |
|
||
|
|

start [/forum/topic.php?all=1&fid=52&tid=1885682]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
181ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 228ms |
| total: | 495ms |

| 0 / 0 |
