|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
Всем привет. Задача немного усложнилась :-( Вот теперь какая задача стоит. Есть селект Код: sql 1.
В таком варианте, он будет сравнивать условия date2>date1 для каждой пробегаемой строчки. Можно ли сделать так, чтобы он date1 брал из текущей строчки для всей суммы, а date2 из каждой пробегаемой? Может, есть какой-то скрытый столбец, определяющий номер пробегаемой строчки. Типа как: Код: sql 1.
В таком варианте date1-row_number() будет возвращать для каждой суммируемой строки одну и ту же дату (даты гарантировано идут последовательно). Но именно так, как я написал, не работает, не принимает он row_number() внутри суммы.... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 11:36 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
ElicAlexey AgafonovЗадача немного усложнилась :-(Вряд ли: 15431514 И опять 15420817 Да, это все мои темы, но мне нужно считать на год вперед для date1. Но есть "фиксируем" date1 и бегаем от нее и до +1 года. Но считаем только те записи, у которых эта "фиксированная" date1>=очередной пробегаемой date2 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 13:46 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
Alexey AgafonovДа, это все мои темы, но мне нужно считать на год вперед для date1.Это аналогичная задача. Если не в состоянии это понять - будь добр предоставить тестовые данные и результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 14:16 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
ElicЭто аналогичная задача. Если не в состоянии это понять - будь добр предоставить тестовые данные и результат. Да, видимо, что-то не догоняю... Сделал файлик и на нем рассмотрел 3 примера. Картинка ниже Итак, date 2 идут последовательно, уже не случайно, как в предыдущем вопросе. Нужно рассмотреть и просуммировать только те записи, которые от рассматриваемой строки не далее, чем +3 дня (то есть рассмотреть 3 записи вперед + сама текущая, итого 4, не дальше). Но суммировать только те строки, у которых date1<=date2 рассматриваемой строки. Например, 2 января. Смотрим + 3 записи вперед, с текущей получается 4 записи. Это 2 - 5 января. Смотрим строки с date1, которые <=2 января, такая только одна, выделена (тоже 2 января). Другой пример, 7 января. Аналогично, смотрим 3 строки вперед, это всего 4 строки, суммируем только те, у которых date1<=7 января. Таких две, они так же выделены. Для всех остальных строк аналогично. Уже голову сломал, как решать. Ниже селект, которым я сформировал эти строки. Там идет random, поэтому при выполнении date1 могут быть разные, date2 строго такая же. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 15:00 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
Alexey AgafonovДа, видимо, что-то не догоняю...Нет. Просто недостаточно доходчиво спрашиваешь. Однопроходно это не решить, IMHO. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 16:37 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
ElicAlexey AgafonovДа, видимо, что-то не догоняю...Нет. Просто недостаточно доходчиво спрашиваешь. Однопроходно это не решить, IMHO. Коллеги предложили конструкцию model, тогда в один проход можэно. Если что-то получится, отпишусь. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 17:10 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
Alexey AgafonovСделал файлик и на нем рассмотрел 3 примера.Если бы в скаляре было условие по одному столбцу, все бы реализовывалось элементарно через аналитику. Код: 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.
Но учитывая, что окно в аналитике необходимо и по date1 и по date2, текущая реализация Оракла не позволяет указать range по обоим их них: analytic function that uses the RANGE keyword can use multiple sort keys in its ORDER BY clause if it specifies any of the following windows . ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 21:22 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
Alexey AgafonovКоллеги предложили конструкцию model, тогда в один проход можэно.Можно, только не взлетит по производительности. Так что разве что для баловства. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2014, 21:24 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
Ну все, нашел ответ в один проход. Вот он, как и обещал: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 13:55 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
Добавлю, что в втащил это в рабочий селект, на ~200 000 строчек отрабатывает за 14 минут, при этом часть ресурсов уходит на склеивание порядка 10-ти таблиц - именно оттуда я получаю потом результаты через MODEL. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 14:00 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
Alexey Agafonov, В модели третье измерение лишнее. При указании порядка, будет работать быстрее. Ну и напоследок сравни производительность модели с merge join. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 15:51 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
dbms_photoshop, Если убираю 3-е измерене, не работает, пишет "ORA-32625: недопустимое измерение в предикате ссылки на ячейку". Вот скрипт: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
На счет merje join - работал на моей таблице более получаса, я срубил. Это явно больше 14 минут. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 16:09 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
Alexey Agafonov, Код: plsql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 17:00 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
dbms_photoshop, На малых данных твой отработал за 8 секунд против моих 17.. Интересно. Запустил по всем 200 000 обеими способами.... Жду... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 18:17 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#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. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57.
Alexey AgafonovНа малых данных твой отработал за 8 секунд против моих 17.. Интересно.Для малых партиций модель работает адекватно, но аналитика обычно быстрее на любых объемах. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2014, 19:54 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
если диапазон небольшой - 3 дня как в вопросе, то можно просто разложить по дельте: Код: 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.
Но на очень больших объемах эффективнее будет с PL/SQL однократным проходом по курсору с сохранением и суммированием только последних удовлетворяющих записей, а те которые ушли за три дня удалять из коллекции и пайпать ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2014, 00:36 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
xtenderесли диапазон небольшой - 3 дня как в вопросе, то можно просто разложить по дельтеЕсли уж говорить про упрощенные варианты, то во-первых работает неправильно, во-вторых лучше избегать "хитрых окон" т.к. они портят производительность . Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2014, 03:58 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
dbms_photoshopто во-первых работает неправильнона самом деле всего лишь невнимательность - просто забыл подправить первый декод: вместо Код: plsql 1. 2. 3. 4.
должно быть Код: plsql 1. 2. 3. 4. 5.
dbms_photoshopво-вторых лучше избегать "хитрых окон" т.к. они портят производительность .а про это можешь мне можешь даже не говорить... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2014, 08:08 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
dbms_photoshop Код: plsql 1.
а я отталкивался от неуникальных date2 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2014, 08:09 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
ну с дырками, конечно.. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2014, 08:16 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
Alexey Agafonovdbms_photoshop, На малых данных твой отработал за 8 секунд против моих 17.. Интересно. Запустил по всем 200 000 обеими способами.... Жду... Да, разложить на decode и взять 4 дня просто и быстро. Но, как и писал, я свел задачу к простейшей. Мой рабочий набор данных - это селект из порядка 10-ти таблиц, ~200 000 строк, есть ключ партиционирования и смотреть надо на год вперед. Поэтому MODEL вижу, как единственный вариант, чтобы не прибешать к PL/SQL. Итак, запустил на ночь оба варианта (с order by и второй без, с дополнительным измерением). Скрипт усложнился, поэтому работал примерно 20 минут. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2014, 10:48 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
[1]: Statement processed in 1214,03 sec; see Spool tab - это с order by [1]: Statement processed in 1316,53 sec; see Spool tab - это без.. Разница в 100 секунд. Формально, dbms_photoshop прав - работает бысрее и это логично (минус одно измерение как минимум прибавляет производительность), но не сильно. Тем не менее оставля. вариант с order by. Мои благодарности к dbms_photoshop! ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2014, 10:51 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
Alexey Agafonov~200 000 строктю... на таком объеме хоть аналитикой, хоть подзапросами должно за минутку-две отработать, только материализовать может быть надо будет ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2014, 11:41 |
|
Еще вопрос по аналитике
|
|||
---|---|---|---|
#18+
-2- Почти модель... Альтернатива покороче если вдруг кому интересно Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2020, 20:17 |
|
|
start [/forum/topic.php?desktop=1&fid=52&tid=1881538]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
53ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 165ms |
0 / 0 |