Как правильно работать с временными таблицами.
На страницу Пред. 1, 2
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
pas
Профи
Вступление в Клуб: 20.11.2007
|
 Пн Окт 24, 2011 13:59 |
 |
Полезность: Нет оценки
|
| vek21 пишет: | .....
Извините, только сейчас увидел, как надо вставлять код программы...
.....  |
не парся  |
|
 |
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Вт Окт 25, 2011 11:00 |
|
Полезность: Нет оценки
|
| vek21 пишет: | Asdn, вы хотите работать с динамической таблицей с помощью select'oв PL/Plus? Это возможно.
|
Как вариант - оригинально. Да, есть и такое решение.
Об этом я не подумал.
Однако есть минусы.
При достаточно большом объеме (на наших базах выведена эмпирическая оценка - более 1 миллиона записей ) у вас будут большие проблемы
а) с памятью
б) с быстродействием
если переключение контекста из pl/sql в sql и обратно происходит достаточно безболезненно, то переключение контекста из SQL в pl/sql (то есть вызов функции из SQL-запроса) замедляет работу запроса в 5-10 раз на 1 вызов одной функции для каждой записи по сравнению с работой того же запроса без функций.
Но если это не критично, то почему нет |
|
|
vek21
Участник со стажем
Вступление в Клуб: 20.09.2007
|
| Вт Окт 25, 2011 11:30 |
|
Полезность: Нет оценки
|
| Random, речь-то идет о динамических таблицах, созданных внутри операции. Вряд ли здесь будут объемы в 1 млн. записей... Мой опыт показывает, что данный способ работы с динамическими таблицами достаточно удобен и не особо чувствуется какое-то замедление в работе операции... Хотя, конечно, тут уже всё зависит от решаемой задачи. |
|
|
Random
Эксперт
Вступление в Клуб: 27.06.2011
|
| Ср Окт 26, 2011 05:47 |
|
Полезность: Нет оценки
|
| vek21 пишет: | | Random, речь-то идет о динамических таблицах, созданных внутри операции. Вряд ли здесь будут объемы в 1 млн. записей... Мой опыт показывает, что данный способ работы с динамическими таблицами достаточно удобен и не особо чувствуется какое-то замедление в работе операции... Хотя, конечно, тут уже всё зависит от решаемой задачи. |
Угу.
Я и говорю - если вышеописанное не критично, то такое решение - вполне хорошее, годное решение
Я его даже использовал, только из головы вылетело.
А насчет "вряд ли будут объёмы"... могу рассказать одну историю.
Как известно, в pl/sql есть массивы, индексируемые по числу.
И вот, для ускорения операций, было решено закэшировать некие данные в разреженный pl/sql-ный массив, используя в качестве индекса значение поля id, которое заполняется, внимание, из сиквенса SEQ_ID. Тоже считали, что идентификатор вряд ли будет больше двух миллиардов...
какое-то время это работало, но однажды очередное значение из сиквенса получило значение больше максимального по размерности, чем pls_integer. И ЦФТ пришлось в спешном порядке по всему продукту искать, где используется эта схема и исправлять.
Выводы сами делайте |
|
|
vtar
Эксперт
Вступление в Клуб: 20.03.2009
|
| Ср Окт 26, 2011 08:08 |
|
Полезность: Нет оценки
|
| Random пишет: | используя в качестве индекса значение поля id, которое заполняется, внимание, из сиквенса SEQ_ID. Тоже считали, что идентификатор вряд ли будет больше двух миллиардов...
|
+1
тоже однажды переписывал локальную доработку, работающую N лет, аффтар которой использовал именно такую реализацию... |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
