|
|
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
Есть запрос: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Казалось бы все нормально, но проставляем теперь группы: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Семенов и Петров попадают в одну группу. Понятно, что т.к. они идут одной датой и другой сортировки нет, то берется произвольно. Т.е. такой косяк может вылезти по идее и при проставлении sog. Но надо все-таки их отделить и на примере Семенова-Петрова должно быть так: если в одной дате есть две фамилии, то за первую фамилию берем ту из них, которая есть в ближайшей более ранней дате. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 17:50 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
На выходе надо получить периоды: Код: plsql 1. 2. 3. 4. Можно было бы обойтись min max с группировкой по фамилии, но фамилии могут повторяться в хронологии (Иванов). Плюс запрос упрощен, в реальном еще потребует патишн бай. Еще вариант, разбирать в коллекции, но интересно посмотреть запросом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 17:57 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
Опиши постановку задачи, что именно требуется получить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 18:21 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
Исх. набор: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Получить надо: Код: plsql 1. 2. 3. 4. То есть периоды с и по для nm. Попутно вопрос, можно ли в операциях с окном (over partition by) при обозначении диапазона rows rows between обращаться к текущему значению для сравнения с предыдущими? Поищу, если найду, то решу. Можно еще было бы попробовать собрать в listagg предыдущие фамилии, но это не вариант, т.к. реально полей больше конечно для сравнения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 18:27 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
Avotge, С некорректными данными либо надо их сначала привести к порядку, либо заниматься статистической оптимизацией иногда_работает vs иногда_не_работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 18:35 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
-2-С некорректными данными либо надо их сначала привести к порядку, либо заниматься статистической оптимизацией иногда_работает vs иногда_не_работает. Можно сказать, что это и есть попытка приведения к порядку ) Пока правда из реального склоняюсь к тому, чтобы засовывать в коллекцию и там делать что надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 18:40 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
AvotgeИсх. набор: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Получить надо: Код: plsql 1. 2. 3. 4. То есть периоды с и по для nm. Попутно вопрос, можно ли в операциях с окном (over partition by) при обозначении диапазона rows rows between обращаться к текущему значению для сравнения с предыдущими? Поищу, если найду, то решу. Можно еще было бы попробовать собрать в listagg предыдущие фамилии, но это не вариант, т.к. реально полей больше конечно для сравнения. сильно не тестировал, так не подойдет Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 20:13 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
AvotgeПолучить надо:Кто на ком стоял? : Код: plsql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 21:01 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
Elic, задачка вроде бы как понятна (дереминирована), но надо акуратно протверезветь ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 21:21 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
stax..задачка вроде бы как понятна (дереминирована),Тебе только кажется. Каждая строчка должна быть досортирована с одной стороны предысторией, с другой - послеисторией. Парадокс. А твоё "решение" - неправильное. Сортировка только по dt недетерминирована. Достаточно поставить второго Семёнова после Петрова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 21:38 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
Elic, сегодня не готов ответіть по существу ps ваше решение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 22:29 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#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. Сильно не проверял, но что-то похожее. Если учесть, что полей для группировки и определения окна больше, плюс еще нюансы, то в реальности запрос получится ну совсем... А если переписать на коллекции, то вообще без стакана лучше не подходить похоже ( Нет. Можно конечно аккуратно все написать, разложить, но столько усилий и объем кода, ради того, чтобы сделать казалось бы простую группировку, это не нормально имхо ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 22:50 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
AvotgeИсх. набор: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Получить надо: Код: plsql 1. 2. 3. 4. То есть периоды с и по для nm.Видимо ты что-то для биллинга ваяешь, но алгоритм до конца не ясен. Приведи данные на которых решение ниже не работает Код: 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. AvotgeМожно было бы обойтись min max с группировкой по фамилии, но фамилии могут повторяться в хронологии (Иванов).Секционируем по фамилии, "вклинивания" других фамилий определяем с помощью decode. AvotgeПопутно вопрос, можно ли в операциях с окном (over partition by) при обозначении диапазона rows rows between обращаться к текущему значению для сравнения с предыдущими? Поищу, если найду, то решу. Можно еще было бы попробовать собрать в listagg предыдущие фамилии, но это не вариант, т.к. реально полей больше конечно для сравнения.Обращаться к текущему значению в аналитике нельзя. Только косвенно используя range и то, если сортировка не более чем по одному полю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2016, 23:47 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopВидимо ты что-то для биллинга ваяешь, но алгоритм до конца не ясен. Приведи данные на которых решение ниже не работает. Не. Надеюсь, в биллинге более стройные данные ) Пока дырки не нашел, вроде все логично, хороший вариант, спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2016, 00:42 |
|
||
|
Расставить sog, непонятка с sum() over()
|
|||
|---|---|---|---|
|
#18+
AvotgeПонятно, что т.к. они идут одной датой и другой сортировки нет, то берется произвольно. Т.е. такой косяк может вылезти по идее и при проставлении sog. "Косяк" потому что у тебя даты одинаковые, соотв аналитика sum over() считает до date_from, а не до current row как тебе нужно для корректного определения начала группы. Добавляешь over(order by date_from, rownum ) как один из вариантов. (Кстати stax не угадал с ",sog" т.к. оно работает только на магии) ) Но вообще, если у тебя поле в таблице date c time то проблем не будет (опять же если не будет exact time). i.e. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2016, 13:11 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39341233&tid=1887082]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
160ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 282ms |
| total: | 513ms |

| 0 / 0 |
