Re: add a new column into the middle of an existing table

M Buckle wrote:

> If your relation (table) is just a bag of unrelated columns, fine, but
> apart from efficiency condiderations, similar kinds of things should
> group together if only for the sake of the poor s*d doing maintenance
> work who is trying to understand the structure and meaning of some
> under-documented system. If foreign keys are to be found together
> near the head of the table, date and timestamps together at the
> bottom, it makes things simpler in the long-run, or perhaps you would
> disagree with such notions along with the use of column naming
> conventions, use of consistent data types etc etc.
>
> Sorry if that sounded like a rant, but your reply sounded like a
> smart-a*se put-down.
>
> Cheers, M
>
> jp_boileau_at_yahoo.com (J.P.) wrote in message news:<7e388bc3.0205010457.701efd87_at_posting.google.com>...
> > You gott'a stop thinking in non Relational-DB style...
> >
> > The physical location of a column is totally irrelevant in a RDBMS.
> >
> > JP
> >
> > leiwang_q_at_hotmail.com (lei wang) wrote in message news:<af074b9c.0204301247.65da02f9_at_posting.google.com>...
> > > Is there an easy way to add a new column into the middle of an
> > > existing table? Seems to me that you have to create a new table and
> > > copies data from the old table. <Alter table add column> statement
> > > will only adds columns at the end of an existing table.
> > >
> > > I am using Oracle 8.1.7 EE on Solaris 2.7.
> > >
> > > Thanks.

Anyone that thinks about reordering columns in a production database should consider the implications on everything from SQL*Loader scripts to insert statements. And the fact that they have, by virtue of this activity, cost any serious company a substantial sum of money in testing for a near gratuitous change.

I will not believe that anyone has ever encountered a database with performance problems where the solution was reordering columns. If there is a performance improvement, something of which my own cursory testing has yet to demonstrate, it must be insignificant.

Daniel Morgan Received on Thu May 02 2002 - 13:54:15 CDT