|
|
|
Историчность при загрузке таблицы (СУБД: Teradata)
|
|||
|---|---|---|---|
|
#18+
Всем привет! Нужна помощь в написании запроса. Текст как таковой не нужен, хочу направление, куда копать. Есть таблица Тrgt, в которой реализована историчность с помощью двух полей StartDt и EndDt, которые показывают период актуальности записи. Есть нюанс: у записи нет первичного ключа, поэтому реализована так называемая блочная историчность: у набора записей есть идентификатор ID_Block, при загрузке очередных данных проверяю, были ли изменения целиком в блоке, если были, то существующий блок закрывается (в поле EndDt записывается ДатаЗагрузки - 1 день), и новый блок с заданным идентификатором открывается. Запрос, который определяет изменения в блоке, в аттаче (Тrgt - существующая таблица, L - таблица с новыми данными. Ежедневно в таблице L приходят данные за один день. Запрос упрощен, если понадобится пояснения, сделаю). Загрузка в Тrgt таблицу происходит ежедневно, и загружается новая порция данных за один день, блочная историчность реализована и работает. Теперь новая задача: надо грузить данные не по дням, а массово - за один год, например, и историчность в этом случае придется строить на лету. То есть в таблицу L загрузили данные сразу за год, а в таблицу Тrgt должны попасть данные с построенной историчностью. Моя проблема заключается в том, что оператор MINUS ALL в запросе оперирует независимыми множествами, а в случае построения истории он должен проверять изменения с прошлого дня, то есть ДанныеЗаТекущийДень MINUS ALL ДанныеЗаПрошлыйДень. Как это можно реализовать? Буду признателен за любые советы. Спасибо! Запросы прикладываю ID - суррогатный PK, ID_Block - идентификатор блока, Value1 - значение, которое меняется в блоке. BlockOrder - это фактически поле StartDt, показывает, в каком порядке пришел блок. Код: 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. Запрос, который определяет разницу в двух смежных блоках (Текущий минус предыдущий. Сравнивается всегда последний пришедший в Trgt блок) Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2012, 13:33 |
|
||
|
Историчность при загрузке таблицы (СУБД: Teradata)
|
|||
|---|---|---|---|
|
#18+
Хорошо бы озвучивать версию Терадаты.В 12, 13 или 13.10 возможны ньюансы. Возможно я не совсем до конца понял задачу при загрузке историчности за год. Но может можно будет через RECURSION VIEW генерить нужный идентификатор для ID_Block. В документации по Терадате это достаточно подробно описанно.Покопай в эту сторону. И ещё, при загрузке больших обьёмов в целевую таблицу созданную через CREATE SET TABLE будут тормоза. Спул будет рости из-за проверки на уникальность записей.Может есть возможность CREATE MULTISET TABLE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2012, 12:16 |
|
||
|
Историчность при загрузке таблицы (СУБД: Teradata)
|
|||
|---|---|---|---|
|
#18+
Не до конца вкурил, но "А может год пришедший бить на дни и в цикле прогонять?" (Да и задача уже решена наверняка... Кстати как?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2013, 22:26 |
|
||
|
|

start [/forum/topic.php?fid=56&msg=37781862&tid=2015235]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
166ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 500ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...