Re: Long columns obsolete

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:3fd23746$0$20482$afc38c87_at_news.optusnet.com.au...
|
| "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
| ------------------------------------
|
|

ok, what's the emoticon for 'tongue-in-cheek'?

seriously, the use of longs in the data dictionary is a regular ORA-997 frustration when doing QA and reverse engineering at customer sites (trying to bring some order to, shall we say, apps born of free-spirit developers) by not being able to include LONG columns in predicates (for DEFAULT_VALUE, DATA_DEFAULT, SEARCH_CONDITION, TRIGGER_BODY, USER_VIEWS.TEXT, COLUMN_EXPRESSION)

• mcs