ChA softwarerименованные параметры-рекордсеты и возможность легко крутить выборки так, как нам удобно, в частности передавать их между подпрограммами и использовать на сервере.
А если не в частности или, точнее, а еще как и где, и через какой интерфейс ?
Продекларировать набор и сказать "вот это полный список и ничего другого нет", я не рискну. И важного для меня - еще асинхронный фетч. Через все интерфейсы, которые это умеют. OCI и JDBC это умеют, насчет прочих - не проверял.
ChAМеня всего лишь заинтересовало, что такое "нормально",
Надеюсь, ответ был дан. Во всяком случае, уточняющих вопросов более не последовало.
ChAи есть ли способ воспользоватся таким способом с помощью стандартов, например, того же ODBC.
Есть. Можно писать "нормальные" ХП и пользоваться ими через ODBC.
ChAИ ежу понятно, что "родной" API обычно богаче возможностями, чем "общепринятые" стандарты.
Что является основной причиной неприменимости "общепринятых" стандартов для серьезных целей.
На всякий случай уточню: еще встречаются.... наивные молодые люди, пытающиеся работать с Oracle через ADO. Бедняги. У яверов практически нет выбора, но там существует возможность расширить драйвер в "нестандартную" сторону, чем Oracle активно пользуется. Что касается пытающихся работать с Oracle через ODBC, то видимо существуют, но в следовых количествах.
ChA softwarerРыться не хочу ввиду вероятности того, что Вы снова расскажете о том, что знали заранее и это неинтересно.Смешно. Правда. Вы ведь здесь не студентам лекции читаете, и если задают вопрос, то не надо начинать с Адама.
С Адама я начинаю ответ на вопрос, если явный новичок задает вопрос на какую-то серьезную тему - такую, что без знания соответствующего адама наверняка накосячит.
В данном случае я отвечал на заданный вопрос. Так как его понял с учетом предполагаемой грамотности собеседника. Если как Вы сейчас ведете, вопрос был "можно ли писать ХП на ODBC", то такой вопрос я не понимаю.
ChAНо приложите хотя бы минимум усилий, чтобы понять, что именно хочет узнать собеседник,
Пытаюсь, в меру своих сил. Надеюсь, Вы собираетесь приложить аналогичный минимум усилий, чтобы быть понятым?
ChA softwarerВ отличие от Вас, я не полагаюсь на "мне кажется".Судя по Вашим ответам, Вам иногда
кажется , что Вы отвечаете на заданные вопросы.
(как я люблю логичные ответы) Согласен. И? Где я "полагаюсь" на это "кажется"? Опять же - именно на это "кажется", а не на более материальные критерии, например на отсутствие уточняющих вопросов. Если нигде - причем тут это? Снова какой-то контекст, которого я не понимаю?
ChAКстати, наша предыдущая дискуссия развивалась подобным же образом. И многие другие до того.
К сожалению, я не помню наших предыдущих дискуссий, во всяком случае в контексте именно Вашего в них участия. Если Вы помните - тем более, почему бы не подстелить соломки заранее и не выражаться максимально четко?
ChA softwarerТак и быть, открою Вам тайну - в поддержке ansi-шных join-ов регулярно отлавливают баги, при том что они поддерживаются уже лет пять, только на днях (в последнем патчсете) закрыли очередной.Я потрясен, а можно я остальным расскажу ?
Хм. Глядя на свое письмо в форуме, на ответ.... такое впечатление, что провоцируете ответить "нет, нельзя".
Меня и самого это изрядно удивляет, но это уже дело оракла, каким криворуким студентам он поручает этот участок работы. С моей точки зрения, этот факт показывает в первую очередь реальное отношение к этой фиче, а также ее практическую востребованность
1 .
1 Востребованность - просто если представить большой проект на ansi join-ах, да еще и не один а хотя бы каждый десятый, я так думаю, все мыслимые баги были бы отрапортованы наткнувшимися на них куда быстрее
ChAНо никак не могу понять, почему некоторые профессионалы в одной СУБД, уверены, что точно знают "слабые" места другой СУБД,
(как я люблю логичные ответы) Не готов говорить за таинственных некоторых профессионалов, посоветовал бы спросить прямо у каждого, начав с топикстартера.
Лично я как основной источник информации использую утверждение профессионалов, не опровергнутых другими профессионалами. Скажем, для построения задачки имени председателя я использовал FAQ форума MSSQL. Чуть ниже я сошлюсь на Вас.
В целом по этому абзацу - будьте добры конкретику. Кто, когда, как и чем плохо. Абстрактные заявления в воздух стоят примерно столько же, сколько сероводород (или что там) объемом в один пук.
ChAХорошо, спрошу иначе: почему Вы решили, что это "существенные накладные расходы" ?
То, что было сказано в топике, в том числе сказано Вами и то, что не опровергнуто Вами, я понял следующим образом: для передачи через ODBC результат выборки формируется целиком. Это означает фактическое удвоение требуемой оперативки
2 - в ней будет лежать собственно временная таблица и та же таблица в виде ODBC-ответа. Удвоение потребности в памяти я полагаю существенными расходами. Разумеется, есть и другие тонкие места, но там уже надо уточнять реализацию, прежде чем что-то утверждать, их я в виду не имел.
2 Здесь я предполагаю, что временная таблица целиком лежит в оперативке как более эффективный вариант. Если это не так и таблица уйдет на диск, это будет еще более существенными расходами.
ChAПоясню, недавно прозвучало уверенное заявление, что таблицы INSERTED и DELETED в триггере строятся невероятно "доооолго".
Насколько я помню, от меня такого заявления не звучало.
ChA softwarerЕсли задаться такой целью, то можно (в Oracle), но имхо малоосмысленная задача.Можно ? Каким образом ?
Криво и тяжело, примерно как ответ председателя на мою задачу :) Судя по направлению развития, прямая фича такого рода должна появиться, но пока придется извращаться, примерно так
3 :
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.
SQL> create type TIntTable is table of integer ;
Type created
SQL> create or replace function Reuse ( intable sys_refcursor ) return TIntTable pipelined is
2 i integer ;
3 begin
4 loop
5 fetch intable into i ;
6 exit when intable%notfound ;
7 pipe row ( i ) ;
8 end loop ;
9 close intable ;
10 return ;
11 end ;
12 /
Function created
SQL> select
2 column_value,
3 chr ( 64 + column_value )
4 from
5 table ( Reuse ( cursor ( select rownum from dual connect by level <= 5 ))) ;
COLUMN_VALUE CHR( 64 +COLUMN_VALUE)
------------ --------------------
1 A
2 B
3 C
4 D
5 E
На всякий случай оговорюсь: я не искал решения такой задачи, может и есть какая-нибудь неизвестная мне фича Oracle, которая позволит действовать напрямую. Из известных мне - приходится вот так.
ChAЕсли буду не прав, и к Oracle нижесказанное не имеет отношения, поправьте.
Сказанное скорее верно, хотя и с оговорками - скажем, там подразумевается, что план вычисляется для каждого запроса, в то время как переиспользование плана - основа эффективности большинства систем, в том числе, насколько мне известно, и в MSSQL. Но вопрос в выводах, которые следует сделать.
Первейшая задача, которую следует решить - не потерять собственно оптимальный план из пространства возможных решений, причем не только "оптимальный на текущий момент", но и "оптимальный с учетом возможных изменений в будущем". Изменения в будущем включают в себя как изменение статистик в данных, так и изменение бизнес-логики (грубо говоря, если есть десять взаиомдействующих подпрограмм, и в одну надо внести изменение, мало кто после этого начнет анализ и редизайн остальных девяти).
Для того, чтобы не потерять оптимальный план, главное - не отсечь лишнего. Надо запретить оптимизатору явно неверные решения, намекнуть на желательные и оставить максимальную свободу выбора в деталях, оценить которые программисту затруднительно. И здесь жесткое разбиение на подзапросы имхо малоудачно. Почему: позволю себе упрощенный пример. Допустим, я пишу что-нибудь типа
1.
2.
3.
4.
5.
6.
7.
8.
with
subquery1 as ( select .. from A, B, C where ..),
subquery2 as ( select .. from D, E where ..)
select
..
from
subquery1, subquery2
where
..
Здесь subquery1 и subquery2 - те подзапросы, на которые Вы разбили бы большой запрос. Так вот, вполне может оказаться, что Вы совершенно правы, и A join B и D join E стоит выполнять прежде других операций, но вот C с точки зрения оптимальности стоит подсоединять самой последней. Однако! Однако C должна быть подсоенинена в первый запрос с точки зрения логики, понимания смысла этого запроса. Хинты в общем запросе дадут здесь оптимум, а разбиение ведет к неприятной коллизии, которая - если говорить о практике - скорее всего будет разрешена не в сторону эффективности.
ChAНасчет интерактивности не уловил, вне контекста,
Ну, самый простой пример такой функциональности - "искать в найденном". То есть временная таблица формируется последовательностью команд пользователя, не просто как промежуточные данные для единственной операции.
ChAВ конце концов, еще хватает источников данных, для которых уже никто и никогда OLEDB-провайдера писать не будет.
Я бы сказал, уже хватает источников, для которых никто и никогда не будет писать ODBC-драйвер. Собственно, многолетняя неисправляемая Microsoft-ом кривизна ODBC-драйвера экселя это иллюстрирует.
