[AccessD] Creating new tables as opposed to updating records in an existing indexed table

Gary Kjos garykjos at gmail.com
Mon Mar 12 15:19:56 CDT 2012


There is a lot of housekeeping and logging of changes that would be
happening. Appending rows to a brand new table with NOLOGGING option
set and then renaming the table and re-establishing the indexes
afterward could make sense. You save all the overhead of the logging
and maintaining of the indexes while the updates are happening. If you
are dealing with 100 million row tables in an Access database you
might very well experience the same issue.

GK

On Mon, Mar 12, 2012 at 2:54 PM, Benson, William (GE Global Research,
consultant) <Benson at ge.com> wrote:
> Long time, no post, didn't want people to think I have stopped thinking about databases entirely.
>
> So here is a question, I was reading this thread (which related to Oracle of course, not Access) and wondering if the "truths" in this post are relative to Oracle only.
>
> It struck me as odd that the recommendation was to create a new table from a multi-million record table, with whatever updated values certain fields required - rather than update the fields directly when the table was indexed. Even though it meant duplicating the table, building all the indexes in the successor table, and sunsetting dropping the predecessor table.
>
> It just boggles my mind that this is so - and I wondered if it is regardless of platform.
>
> http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:6407993912330
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com



-- 
Gary Kjos
garykjos at gmail.com



More information about the AccessD mailing list