Simpler Navigation for Servers and Operating Systems - Please Update Your Bookmarks
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
If you have bookmarked forums or discussion boards in Servers and Operating Systems, we suggest you check and update them as needed.
Showing results for 
Search instead for 
Did you mean: 

Oracle columns

Go to solution

Oracle columns

This is a performance related question.
What factors should be considered when creating multiple (30-50) column tables?
I am trying to give input to my developers on the performance related issues that may occur when doing inserts/updates/deletes on a table that has 2-3 columns as opposed to one that has 20-30 columns?
A. Clay Stephenson
Acclaimed Contributor

Re: Oracle columns

This is one of the classic it depends question. If the question is "Is one insert of a 30 column table faster than 10 inserts into tables of 3 columns each?" The answer is one table is much faster especially when you realize that you must have some sort of 'glue' (joins) to hold these 10 related tables.

The general answer to this question is make the number of columns larger but limit the number of indices. Performance tends to really suffer when the value of one column changes and that causes 15 indices to be altered.
If it ain't broke, I can fix that.
Bill Thorsteinson
Honored Contributor

Re: Oracle columns

General rules of thumb:

Primary key columns first.
Foreign key columns next.
Frequently searched columns next.
Frequently updated columns later.
Nullable columns last.
Least used nullable columns after more frequently used nullable columns.
Blobs in own table with few other columns.

Performance issues:

Chained rows (row doesn't fit in a block -> multiple reads).
Updating indexed columns.
Updating indexed columns in block.
Updates increasing row size (row migration or chaining).
Trailing null columns not written to database (less data).


Normalize data.
Don't split tables for performance. (Possible
exception for tombstone data
versus high update derived
data, such as product info and
product inventory info).
Don't spend too much time tuning the database before