Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Обработка древовидных структур
|
|||
|---|---|---|---|
|
#18+
Товарищи здравствуйте! Существует модельная таблица следующей структуры: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. UIDSCHET_DTANALYT_DT#1#ANALYT_DT#2#TYPE_ANALYT_DT#1#TYPE_ANALYT_DT#2#SCHET_KTANALYT_KT#1#ANALYT_KT#2#TYPE_ANALYT_KT#1#TYPE_ANALYT_KT#2#DATE_PROVMNTH_PROV10001ШиныКамаз120002ПокупкаПрямые затраты342018-01-152018-01-0120002ПокупкаПрямые затраты340003Приобретение ТМЦСторонние компании562018-01-122018-01-0130003Приобретение ТМЦСторонние компании560004Договор №1ООО РОГА И КОПЫТА782018-01-102018-01-0140003Приобретение ТМЦСторонние компании560004Договор №2ЗАО ШИНПРОМТОРГ782018-01-052018-01-01 Идея состоит в том, чтобы определить от какого контрагента поступили шины, а именно получить таблицу вида: UID КЛЮЧЕВОЙ ЗАПИСИ UID ЗАПИСИ-ИСТОЧНИКА1314 Явно просматривается иерархия. Я знаю как решить данную задачу, используя процедурный подход, но производительность при нем крайне неудовлетворительна - 1кк записей обрабатываются за ~4 часа. Мне кажется, что рекурсивное CTE поможет, но не могу сообразить как построить запрос. Требования к данным при поиске: Дебет каждой последующей записи в иерархии(потомок) должен равняться кредиту предыдущей записи(родитель); Дата проведения(DATE_PROV) потомка должна быть в интервале [MNTH_PROV ;DATE_PROV ] родителя; Запись считается интересующей, если для проводки существует аналитика с типом 8(Организация). Сейчас поиск данных производится при помощи рекурсивной процедуры на стороне клиента, но это жутко медленно. SQL SERVER 2008R2. Прошу помочь с данным вопросом. Заранее благодарю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2018, 14:44 |
|
||
|
Обработка древовидных структур
|
|||
|---|---|---|---|
|
#18+
Oomel, А почему Вы не хотите нормализовать данные? Зачем в одну кучу свалили? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2018, 14:51 |
|
||
|
Обработка древовидных структур
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов, система была разработана до меня, ведение учета было настроено без оглядки на здравый смысл. Изменить методику учета никто не хочет. Переписать БД возможности нет из-за огромного количества зависимостей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2018, 14:53 |
|
||
|
Обработка древовидных структур
|
|||
|---|---|---|---|
|
#18+
Oomel, Если глубина вложений постоянна - постройте два объединения таблицы самой к себе по указанным Вами условиям. Рекурсия хорошо работает только для одного корневого элемента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2018, 15:40 |
|
||
|
Обработка древовидных структур
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовOomel, Если глубина вложений постоянна - постройте два объединения таблицы самой к себе по указанным Вами условиям. Рекурсия хорошо работает только для одного корневого элемента. Глубина неизвестна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2018, 16:05 |
|
||
|
Обработка древовидных структур
|
|||
|---|---|---|---|
|
#18+
Oomel, Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2018, 20:25 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39647604&tid=1689692]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
44ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
| others: | 217ms |
| total: | 359ms |

| 0 / 0 |
