Subject | Re: [Firebird-Architect] Counter proposal to Temporary tables |
---|---|
Author | Paulo Gaspar |
Post date | 2004-12-04T15:07:59Z |
I actually have more experience with Oracle then with Sybase/MS
SQLServer and I find LTTs much more convenient than Oracle collections.
LTTs can be handled trough SQL just like any other table. You usually
end up having to code a lot more when using Oracle's collections.
(Besides, Oracle's collections still have - at least until 9i - a
feeling of "work in progress" due to ccouple of akward restrictions here
and there.)
In SQLServer using LTTs was eseential (at least when I still used them,
many years ago) due to the limitations of their cursor implementations -
especially in terms of performance. But even with the much nicer cursor
implementation in Oracle, I still missed them a lot.
Take this just as the POV of a developer that used them and also knows a
couple of alternatives.
Regards,
Paulo Gaspar
Dmitry Yemanov wrote:
...
SQLServer and I find LTTs much more convenient than Oracle collections.
LTTs can be handled trough SQL just like any other table. You usually
end up having to code a lot more when using Oracle's collections.
(Besides, Oracle's collections still have - at least until 9i - a
feeling of "work in progress" due to ccouple of akward restrictions here
and there.)
In SQLServer using LTTs was eseential (at least when I still used them,
many years ago) due to the limitations of their cursor implementations -
especially in terms of performance. But even with the much nicer cursor
implementation in Oracle, I still missed them a lot.
Take this just as the POV of a developer that used them and also knows a
couple of alternatives.
Regards,
Paulo Gaspar
Dmitry Yemanov wrote:
...
>Oracle offers both table variables and collections in PL/SQL. Perhaps this
>is the reason they don't bother implementing LTTs. Or perhaps they are
>exactly LTTs in everybody's understanding, but without a standard syntax. If
>we won't be able to agree on LTTs, this might be a way to continue this part
>of our discussion.
>
>
>Dmitry
>
>
>