Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Выковыриваю повторяющуюся группу из XML-поля.
|
|||
|---|---|---|---|
|
#18+
Имеется файл с xml-полями такого типа: Код: plaintext 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. Повторяющийся тэг - <СуммаПоКБК>, остальные ветки присутствуют по одной штуке на каждое XML-поле. Надо выгрузить в одну табличку типа: <Месяц>; <Год>; <ДатаФормирования>; <НомерФилиала>; <КодВыплатыПоКБК>; <Сумма> Такое сочинил, работает, возвращает столько строк, сколько записей в таблице: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. Такое сочинил, выдаёт по строчке на каждую группу <СуммаПоКБК>: Код: plsql 1. 2. 3. 4. 5. 6. Пытаюсь как-то 2 вышеописаные скрестить. Спинной мозг подсказывает что-то вроде этого: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Но оно не работает и кучеряво ругается: SQL16003N Выражение с типом данных "( item(), item()+ )" нельзя использоватьSQL16003N Выражение с типом данных "( item(), item()+ )" нельзя использовать, если в контексте ожидается тип данных "CHAR_100". QName ошибки =err:XPTY0004. SQLSTATE=10507 SQL16003N Выражение с типом данных "( item(), item()+ )" нельзя использовать, если в контексте ожидается тип данных "CHAR_100 ". QName ошибки =err:XPTY0004. Объяснение: Выражение XQuery содержит значение с типом "<тип_значения>" в контексте, в котором предполагается тип "<ожидаемый_тип>". Выражение XQuery нельзя обработать. И более того, даже вот такое не работает и так же ругается: Код: plsql 1. 2. 3. 4. 5. 6. Т.е. "рубить" надо, видимо, по тегу, в котором повторения начинаются, но как тогда значения из других веток цеплять непонятно. Поможите люди добрые и далее по тексту!... Особенно эфеективно поможет ссылочка на большой, но внятный текст про то, как обращаться с XML-полями. На IBM нашёл чего-то, но отрывочно и не всегда понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2012, 12:17 |
|
||
|
Выковыриваю повторяющуюся группу из XML-поля.
|
|||
|---|---|---|---|
|
#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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2012, 15:50 |
|
||
|
Выковыриваю повторяющуюся группу из XML-поля.
|
|||
|---|---|---|---|
|
#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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2012, 16:24 |
|
||
|
Выковыриваю повторяющуюся группу из XML-поля.
|
|||
|---|---|---|---|
|
#18+
Mark Barinstein, А точно лучше (в общем случае, с достаточно большими XML'ями)? Когда мы от текущей ноды вверх идём в XPath могут быть условия, зависящие от контекста. Оно достаточно умное, чтобы в одном случае выдернуть ..\.... один раз, а в другом каждый раз вычислять? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2012, 18:29 |
|
||
|
Выковыриваю повторяющуюся группу из XML-поля.
|
|||
|---|---|---|---|
|
#18+
CawaSPbА точно лучше (в общем случае, с достаточно большими XML'ями)? Когда мы от текущей ноды вверх идём в XPath могут быть условия, зависящие от контекста. Оно достаточно умное, чтобы в одном случае выдернуть ..\.... один раз, а в другом каждый раз вычислять?Не знаю, мне негде проверить. Но подозреваю, что производительнее обрабатывать xml документ 1 раз, чем 2. Вот Автор темы нам может и подскажет, как оно там лучше... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2012, 18:42 |
|
||
|
Выковыриваю повторяющуюся группу из XML-поля.
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinНе знаю, мне негде проверить. Но подозреваю, что производительнее обрабатывать xml документ 1 раз, чем 2. Хм, логично. Число ситуаций, когда можно бросить парсинг, не пропарсив весь документ - ограничено, да и парсер должен быть для этого достаточно умным. Mark BarinsteinВот Автор темы нам может и подскажет, как оно там лучше... Да, было бы интересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2012, 19:03 |
|
||
|
Выковыриваю повторяющуюся группу из XML-поля.
|
|||
|---|---|---|---|
|
#18+
Большого объёма данных пока нет и продвинутыми методами анализа я не владею. Поэтому могу предложить только вот такое: ссылка на изображение, размер: 13.7 кбайт, 792 x 383 точек Слева один проход, справа 2. 2 совсем чуть-чуть быстрее. Видимо, откучивать назад по XML неудобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2012, 20:24 |
|
||
|
Выковыриваю повторяющуюся группу из XML-поля.
|
|||
|---|---|---|---|
|
#18+
Честный чайник, По explain'у это всё несколько условно. Но интересно уже то, что, похоже, оно догадалось объеденить два скана XML документа в один. Но чтобы точнее сказать, надо просто "в лоб" проверить: а) запихать в табличку XML, где элементов <СуммаПоКБК> будет с пару миллионов; б) наоборот, обычный небольшой XML с обычным количеством <СуммаПоКБК>, но таких строчек нагенерить с те же пару миллионов. И на тех, и на других данных попробовать оба варианта запроса. Будет познавательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2012, 02:55 |
|
||
|
|

start [/forum/topic.php?fid=43&fpage=46&tid=1601898]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
67ms |
get topic data: |
12ms |
get forum data: |
7ms |
get page messages: |
95ms |
get tp. blocked users: |
1ms |
| others: | 304ms |
| total: | 517ms |

| 0 / 0 |
