Jan Gelbrich wrote:
> BTW, how about Oracles´ own tables containing LONGs ?
> In 8i (8.1.7.3 - yaya, old version, but still in service widely), I find a
> lot of them:
>
> SQL> select table_name from dba_tab_columns where data_type = 'LONG';

[Almighty Snip]

> 193 Zeilen ausgewählt.

Anything wrong with doing a count(table_name) and saving us all some
bandwidth?

> That is quiet a lot, isn´t it ?

Yes, it is quite a lot.

[snip]

> in the middle of the definition, not at the end as suggested by
> another poster.

You are allowed to actually remember the names of people who take the
trouble to reply to you, you know! In any case, I didn't "suggest" it,
but said that because of the in-line storage of LONGs it was sensible to
shove them to the end of the definition -which is merely reporting a
suggestion made by Oracle themselves (though clearly not one they
*adopt* themselves).

> Has it all changed or gone with 9i / 10g ?

No, it's still there in 9i and 10g. Indeed, there have been some
enhancements to LONG functionality in 10g (it's a newly-supported data
type in streams, for example).

But so what? Oracle breaks its own advice, and we're supposed to do
likewise?? Oracle does all sorts of 'strange' things that you'd never do
yourself (take a look at the defaults on SYSTEM tablespace, for example;
or ask why there is still a good old-fashioned SYSTEM rollback segment
when we're all supposed to be using undo tablespaces and automatic
undo). What Oracle does with its data dictionary is up to it, basically,
though I have no doubt that there is, or will be, a project underway to
gradually convert the data dictionary to CLOB technology. However, given
the size of the data dictionary, its crucial importance to a
properly-functioning database and its complexity, that's a massive
undertaking, and not one they would implement lightly.

Oracle, in other words, are stuck with LONGs because the DD has been
around for ages. A bit like MS being saddled with DOS substrates in
their consumer operating systems for so long when they really wanted
everyone to move to NT-type technology (and finally got them to do so
with XP). If you are developing a new application/database, you are not
constrained by such a history, and have the choice of adopting a
technology which Oracle has publicly deprecated and which comes with
major size and functionality limitations, or a technology which doesn't
come with those problems. I know which one I'd be choosing!

Regards
HJR