Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Database Design questions

Re: Database Design questions

From: <>
Date: Fri, 18 Jun 2004 09:55:17 -0400 (EDT)
Message-ID: <>

Denormalization has its place and time, but i'm not sure this is what you want here, if you dig into the concepts of modeling gurus, kimball, etc, you'll see that you should break those out and try to eliminate redundant data. Your question is a bit open ended, are you trying to aatian 3rd normal form, is it oltp, olap, warehouse, etc. As for performance,


original message below

 Hi Design Experts,

     I am in the process of designing a datamodel for  a new application and I need some advice regarding  that. I have a table with almost 130 columns in it.  This table gets updated with new information regularly  and all the columns are mostly dependent or related to  the primary key. I think there will be a poor  performance with the table of this size. My question  is it better of breaking this table into several  different tables like

 property_details ( prop_id (pk), prop address, bed  rooms,bath rooms ,total sqft ...)
 property_auctions ( prop_id (fk), auction date,  auction location..)
 property_loans, (prop_id (fk), loan date, loan amount,  loan recording date...)
 property_defendents (prop_id (fk), defendent owner  firstname, lastname, company name ...)

 Each of these tables will have prop_id as a Foreign  Key (which is also a primary key for that table )  referencing the prop_id Primary Key in this case  parent table property_details.

  1. Is this a good design for such a big table size ?
  2. If I choose this approach and when i need to get all the information for a property I will end up querying all the tables and will involve joining all the tables, which would also affect the performance of the query.

 Can anyone help please help me with the problem ?  Below you will see the huge table which I am talking  about.


<table desc snipped>

Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
Received on Fri Jun 18 2004 - 09:03:23 CDT

Original text of this message