Re: BTW LONG: how about Oracle itself ?

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 Received on Thu May 06 2004 - 03:08:33 CDT