Re: Long columns obsolete

"Mark C. Stock" <mcstockX_at_Xenquery .com> wrote in message news:Do2dnfXcJK7hV0yiRVn-uA_at_comcast.com...
>
>
> Good advise. I suppose eventually Oracle will follow it. ;-{)
>
> Connected to:
> Oracle9i Enterprise Edition Release 9.2.0.2.0 - Production
> With the Partitioning, OLAP and Oracle Data Mining options
> JServer Release 9.2.0.2.0 - Production
>
> SQL> select owner, table_name, column_name
> 2 from all_tab_columns
> 3 where table_name like 'ALL\_%' escape '\'
> 4 and DATA_TYPE = 'LONG'
> 5 /
>
> OWNER TABLE_NAME COLUMN_NAME
> ---------- ------------------------------ ---------------------
> SYS ALL_ARGUMENTS DEFAULT_VALUE
[snip]

As I've always said, the data dictionary breaks all the good rules known to Mankind and DBAs. Its data file has autoextend on by default. Extent sizes are wild and varied. It's data dictionary managed, even in 9iR2 by default. And the tables use LONGS. And as I've also always said, who cares? How many data dictionary tables are you going to 'alter ... move' (where longs would cause a problem)? How many times is Oracle going to store 2GB of data in those tables (where long's in-line storage is going to cause a problem compared to CLOB's out-of-line)? How often are you going to implement replication and partitioning on those tables (ditto)?

Oracle's point has always been that when developing your *own* applications, you *are* likely to want to move, to store out of line, to index and gain random access to chunks, to store data larger than 2GB, and to implement partitioning and replication... all of which are problematic with LONGs, so you'd be daft to use them for your own stuff. But the data dictionary is a bit of backwater as far as cutting-edge requirements are concerned, so they'll suit us just fine, thanks all the same. Besides which, they probably don't fancy re-designing and regression testing the one component that's common to every Oracle database on the face of a planet. Bit of a show-stopper if they get it wrong.

Which is why the use of LONGs is deprecated, not obsoleted.

One only follows advice when it makes sense to do so. It would bring no real benefit to do so for the data dictionary, and there would be plenty of down-side risks during the transition.

Regards
HJR

-- 
------------------------------------
Oracle insights at www.dizwell.com
------------------------------------